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?

Ruby 1.9.2-head

p require_relative('foo')

module Kernel
p method_defined?(:require_relative)
end

produces

true
false

Huh?

···

On Fri, Jun 4, 2010 at 1:27 PM, Intransition <transfire@gmail.com> wrote:
--
The best way to predict the future is to invent it.
-- Alan Kay

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.

···

--
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 Biedenharn

  Rob@AgileConsultingLLC.com

  rab@GaslightSoftware.com

···

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

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.

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

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 Jun 4, 8:18 am, Rob Biedenharn <R...@AgileConsultingLLC.com> wrote:

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

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 Fri, Jun 4, 2010 at 3:24 PM, Intransition <transfire@gmail.com> wrote:

On Jun 4, 8:18 am, Rob Biedenharn <R...@AgileConsultingLLC.com> 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.

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

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 Thomas'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.

···

On Jun 4, 9:42 am, Robert Dober <robert.do...@gmail.com> 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:

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 Dober <robert.do...@gmail.com> wrote:

> 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: