Method_defined? does what exactly?

Ruby 1.9.2-head

p require_relative(‘foo’)

module Kernel
p method_defined?(:require_relative)
end

produces

true
false

Huh?

Hmm maybe I was not very clear in my last post :wink:

require_relative is defined in Object

ruby -ve ‘p method( :require_relative)’
ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]
#<Method: Object#require_relative>

ruby -ve ‘p Object.method( :require_relative )’
ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]
#<Method: Class(Object)#require_relative>

However

ruby -ve ‘p Object.methods.grep( /require/ )’
ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]
[]
^^^^ ???

Maybe a tiny bug here?

Cheers
R.

On Fri, Jun 4, 2010 at 1:27 PM, Intransition [email protected]
wrote:

On Jun 4, 2010, at 8:04 AM, Robert D. wrote:

#<Method: Class(Object)#require_relative>
Cheers
R.


The best way to predict the future is to invent it.
– Alan Kay

No bug (in Ruby). The method is private.

$ ruby -ve ‘p Object.private_instance_methods.select{|m| m.to_s =~ /
require/ }’
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin9.8.0]
[:require_relative, :require]

-Rob

Rob B.
http://agileconsultingllc.com
[email protected]

[email protected]

On Jun 4, 8:18 am, Rob B. [email protected] wrote:

No bug (in Ruby). The method is private.

Damn it! I can’t tell you how many time I’ve been bitten by that.
There REALLY needs to be a convenient way to check ALL methods,
public, private and protected.

Of course I’ve said this the last time this came up too, but you know,
who cares. Array#repeated_permutation is much more important.

On Fri, Jun 4, 2010 at 3:24 PM, Intransition [email protected]
wrote:

On Jun 4, 8:18 am, Rob B. [email protected] wrote:

No bug (in Ruby). The method is private.

Damn it! I can’t tell you how many time I’ve been bitten by that.
There REALLY needs to be a convenient way to check ALL methods,
public, private and protected.

Of course I’ve said this the last time this came up too, but you know,
who cares. Array#repeated_permutation is much more important.

I agree with you and I would like to add that #method returns all
kind of methods and there is no method #private_method.
Would be too nice to have
#method(s), #private_method(s), #public_method(s) and
#protected_method(s)
shrug.

Consistency does not seem to be important to most, I have made this
experience before, and that has to be accepted :frowning:

R.

On Jun 4, 9:42 am, Robert D. [email protected] wrote:

experience before, and that has to be accepted :frowning:
Oh, and one more thing.

a.product(a) == a.repeated_permutation(2).to_a
a.product(a,a) == a.repeated_permutation(3).to_a
a.product(a,a,a) == a.repeated_permutation(4).to_a

On Jun 4, 9:42 am, Robert D. [email protected] wrote:

I agree with you and I would like to add that #method returns all
kind of methods and there is no method #private_method.
Would be too nice to have
#method(s), #private_method(s), #public_method(s) and #protected_method(s)
shrug.

Consistency does not seem to be important to most, I have made this
experience before, and that has to be accepted :frowning:

I think it is more than that. I don’t see much evidence that there is
a great deal of consideration going into these additions at all. I
watched Dave T.'s “Ruby Sucks” talk yesterday, and he tried to
paint a rosy picture around the whole thing. I agree with him to the
extent that its cool that ruby is so flexible, but when he mentioned
how they just throw methods in there, “Is it useful? Well I used it
once. Okay!” That just struck a bad nerve. I do not see a whole lot of
rational for what is getting into the language. But it’s also not just
stuff getting thrown in there. It’s clearly selective, but on some
esoteric, perhaps nepotist, or maybe it’s as simple as a C coders
clique making all the choices --actually I do think that is part of
the problem. The people who write Ruby are first and foremost C
coders, not Ruby programmers. I think most of them use Ruby like
others use Perl --as an admin and tools language; as opposed to an
applications framework. Of course, I don’t know the actual reasons,
but clearly something must explain it --I could easily name a dozen
widely used extensions off the top of my head that make most of
1.9.2’s new methods look absolutely lonely.

I think if there were a rational process of determining what would be
best to add to the language, it would be a careful cross-comparison of
the most popular gems out there today. Look at they have common, the
methods, idioms and patterns. Then figure out the best way to support
these things in Ruby proper to the benefit them all.

trans.