Ruby Forum Ruby-core > Am I right that this is wrong?

Hi --

  *  call-seq:
  *     mod.instance_methods(include_super=true)   => array
  *
  *  Returns an array containing the names of public instance methods
  *  in the receiver. For a module, these are the public methods; for a
  *  class, they are the instance (not singleton) methods. With no
  *  argument, or with an argument that is <code>false</code>, the
  *  instance methods in <i>mod</i> are returned, otherwise the methods
  *  in <i>mod</i> and <i>mod</i>'s superclasses are returned.

Since include_super defaults to true, I believe the "With no argument"
statement is wrong. These arbitrary boolean arguments are definitely
confusing, so I just wanted to make sure I'm right that it's wrong.


David

On Wed, Aug 13, 2008 at 9:33 AM, David A. Black <dblack@rubypal.com> 
wrote:
>  *  in <i>mod</i> and <i>mod</i>'s superclasses are returned.
>
> Since include_super defaults to true, I believe the "With no argument"
> statement is wrong. These arbitrary boolean arguments are definitely
> confusing, so I just wanted to make sure I'm right that it's wrong.

I think you're right:

>> String.instance_methods == String.instance_methods(true)
=> true
>> String.instance_methods == String.instance_methods(false)
=> false

I'd actually prefer it as documented, rather than as implemented.
It'd be nice to default as hiding the parent methods.
But that's a whole other can of worms.

On Aug 13, 2008, at 9:55 AM, Gregory Brown wrote:

> I'd actually prefer it as documented, rather than as implemented.
> It'd be nice to default as hiding the parent methods.
> But that's a whole other can of worms.

I agree 100%

Hi,

In message "Re: [ruby-core:18263] Am I right that this is wrong?"
    on Wed, 13 Aug 2008 22:33:18 +0900, "David A. Black" 
<dblack@rubypal.com> writes:

|  *  call-seq:
|  *     mod.instance_methods(include_super=true)   => array
|  *
|  *  Returns an array containing the names of public instance methods
|  *  in the receiver. For a module, these are the public methods; for a
|  *  class, they are the instance (not singleton) methods. With no
|  *  argument, or with an argument that is <code>false</code>, the
|  *  instance methods in <i>mod</i> are returned, otherwise the methods
|  *  in <i>mod</i> and <i>mod</i>'s superclasses are returned.
|
|Since include_super defaults to true, I believe the "With no argument"
|statement is wrong. These arbitrary boolean arguments are definitely
|confusing, so I just wanted to make sure I'm right that it's wrong.

The documentation is wrong, as you say.  If many prefer the documented
behavior and want to change it, it is another story.

              matz.

Hi --

On Thu, 14 Aug 2008, Yukihiro Matsumoto wrote:

> |  *  class, they are the instance (not singleton) methods. With no
> |  *  argument, or with an argument that is <code>false</code>, the
> |  *  instance methods in <i>mod</i> are returned, otherwise the methods
> |  *  in <i>mod</i> and <i>mod</i>'s superclasses are returned.
> |
> |Since include_super defaults to true, I believe the "With no argument"
> |statement is wrong. These arbitrary boolean arguments are definitely
> |confusing, so I just wanted to make sure I'm right that it's wrong.
>
> The documentation is wrong, as you say.  If many prefer the documented
> behavior and want to change it, it is another story.

There was a discussion about this at the Ruby Hoedown. As Jim Weirich
pointed out, the nice thing about doing it the other way around is
that you could do:

   MyClass.instance_methods(:ancestors => true)

or

   MyClass.instance_methods(:with_ancestors)

or whatever, whereas to make the argument false, you have to use false
or nil which is very cryptic.


David

On Wed, Aug 13, 2008 at 3:04 PM, David A. Black <dblack@rubypal.com> 
wrote:
>> |  *  call-seq:
>> |statement is wrong. These arbitrary boolean arguments are definitely
>
> or
>
>  MyClass.instance_methods(:with_ancestors)
>
> or whatever, whereas to make the argument false, you have to use false
> or nil which is very cryptic.

Are you suggesting keeping a boolean signature and then passing things
like this in?
I think that's a little nasty.

I've done stuff like:

some_method_with_boolean_args(do_something=true)

But I would feel uncomfortable with

some_method_with_boolean_args(:do_something)

I'm totally aware that in practice, there is little difference between 
the two.
However, I dislike the idea of a convention that creates a 'fake'
signature, especially in the first case.

MyClass.instance_methods(:ancestors => true)

makes me think that I can do:

MyClass.instance_methods(:ancestors => false), and without a change to
the signature, that wouldn't be the case.

-greg

Hi --

On Thu, 14 Aug 2008, Gregory Brown wrote:

>>>
>>> |Since include_super defaults to true, I believe the "With no argument"
>>  MyClass.instance_methods(:ancestors => true)
> I think that's a little nasty.
> However, I dislike the idea of a convention that creates a 'fake'
> signature, especially in the first case.
>
> MyClass.instance_methods(:ancestors => true)
>
> makes me think that I can do:
>
> MyClass.instance_methods(:ancestors => false), and without a change to
> the signature, that wouldn't be the case.

I would actually prefer there to be separate methods for all these
permutations (and I think Jim W. agrees). I just dislike the cryptic
"false" so much that I'd rather do almost anything else.


David

On Wed, Aug 13, 2008 at 5:43 PM, David A. Black <dblack@rubypal.com> 
wrote:

> I would actually prefer there to be separate methods for all these
> permutations (and I think Jim W. agrees). I just dislike the cryptic
> "false" so much that I'd rather do almost anything else.

Separate methods would be nice.  What would you call them, though?

On Aug 13, 6:56 pm, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
> On Wed, Aug 13, 2008 at 5:43 PM, David A. Black <dbl...@rubypal.com> wrote:
>
> > I would actually prefer there to be separate methods for all these
> > permutations (and I think Jim W. agrees). I just dislike the cryptic
> > "false" so much that I'd rather do almost anything else.
>
> Separate methods would be nice.  What would you call them, though?

You guys don't think

  MyClass.public_instance_methods_with_ancestors

Is getting to be a bit much?

What about using "symbolic logic"?

  MyClass.instance_methods(:public & :ancestors)

I've always thought ruby symbols would make an excellent alternative
to integer flags. For instance I hate:

  Dir.glob(fooname, File::FNM_CASEFOLD)

I'd much rather:

  Dir.glob(fooname, :casefold)

T.

Hi --

On Thu, 14 Aug 2008, Gregory Brown wrote:

> On Wed, Aug 13, 2008 at 5:43 PM, David A. Black <dblack@rubypal.com> wrote:
>
>> I would actually prefer there to be separate methods for all these
>> permutations (and I think Jim W. agrees). I just dislike the cryptic
>> "false" so much that I'd rather do almost anything else.
>
> Separate methods would be nice.  What would you call them, though?

Maybe stick "all_" on the beginning for the "true" version. The
problem though is that the default has been the ancestor version for a
long time.


David

On Aug 13, 2008, at 7:26 PM, David A. Black wrote:

> Maybe stick "all_" on the beginning for the "true" version. The
> problem though is that the default has been the ancestor version for a
> long time.

You could use a proxy

   Thing.own.instance_methods

   Thing.all.instance_methods

Hi,

In message "Re: [ruby-core:18275] Re: Am I right that this is wrong?"
    on Thu, 14 Aug 2008 04:04:12 +0900, "David A. Black" 
<dblack@rubypal.com> writes:

|There was a discussion about this at the Ruby Hoedown. As Jim Weirich
|pointed out, the nice thing about doing it the other way around is
|that you could do:
|
|   MyClass.instance_methods(:ancestors => true)
|
|or
|
|   MyClass.instance_methods(:with_ancestors)
|
|or whatever, whereas to make the argument false, you have to use false
|or nil which is very cryptic.

Interesting.  But in a dynamic language like Ruby, inheritance is just
a mean to share methods and other attributes among classes, so that
it's not as important as in static typed languages e.g. Java.  When we
want to know the instance methods of a class, we have more focus on
the list of methods effective in the instances of the class, not the
list of methods defined (but not inherited) in particular class.
Considering the less importance of inheritance in Ruby, I think the
default should be as it is implemented now.

If you want to have separate method to get the no-ancestors list of
methods, it's OK as long as we get the "right" name for it.

              matz.

Hi --

On Thu, 14 Aug 2008, Yukihiro Matsumoto wrote:

> |
> want to know the instance methods of a class, we have more focus on
> the list of methods effective in the instances of the class, not the
> list of methods defined (but not inherited) in particular class.
> Considering the less importance of inheritance in Ruby, I think the
> default should be as it is implemented now.

I understand, but I'll add that in practice, I find myself using
(false) more often than not. When I'm asking classes about their
instance methods, it's usually to find out something like which
methods they've overridden:

   Array.instance_methods(false) & Enumerable.instance_methods(false)

and things like that. Most of the time, the question "What can an
instance do?" seems to be handled at the instance level, with #methods
or #respond_to?

> If you want to have separate method to get the no-ancestors list of
> methods, it's OK as long as we get the "right" name for it.

How about "instance_methods!" :-)


David