On Tuesday, September 28, 2004, 5:49:21 PM, Robert wrote:

>> Actually, I agree with you too. Since it's just a flag, perhaps using
>> meaningful symbols would be better?
>>
>>   methods(:public)
>>   methods(:private)
>>   methods(:protected)
>>
>>   methods(:no_ancestors)
>>   methods(:ancestors_only)
>>
>>   methods(:class)        # same as self.class.methods ?
>>   methods(:singleton)
>>
>> And they could be combined:
>>
>>   methods(:private, :protected)
>>   methods(:singleton, :private)
>>   methods(:private, :no_ancestors)

> Combining the results is the only advantage of this approach. Still I
> prefer simple and short method implementations (which are less error prone
> and often more efficient).  So if you use symbols, change method names:

> public_methods()
> private_methods()
> protected_methods()

> local_methods()
> inherited_methods()

> drop:  methods(:class)        # same as self.class.methods ?

> singleton_methods()

I completely disagree, Robert.  Lots of related methods is a code smell
to my nose.  Elegant solutions are generally well factored, rather than
expanded all over the top level.  One should aim to keep like things
together, and different things apart.

There are two possible factorings.  Have Object#methods return a
specialised object, thus:

  foo.methods.private
  foo.methods.all
  foo.methods.new
  foo.methods.singleton
  foo.methods[:new, :protected]   # if you need combination
  # etc.

The other possible factoring is as above:

  foo.methods(:new)
  foo.methods(:private)
  foo.methods(:singleton, :private)
  # etc.

Aesthetically, I think I prefer the top one.  But even the second one
is far preferable to the current state of Ruby, to my mind.

In general, you dislike using symbolic arguments to tune a method's
behaviour.  I like it, and consider it quite consistent with the
general practices of good programming.

Cheers,
Gavin