From: Robert Klemme <bob.news@...>
Date: 2004-09-28T20:44:22+09:00
Subject: Re: Best name for "this method" ?


"Gavin Sinclair" <gsinclair@soyabean.com.au> schrieb im Newsbeitrag
news:1801770404777.20040928194159@soyabean.com.au...
> 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.

Agree and disagree: after thinking a bit about the issue I think that
those symbol arguments are not as bad as I thought earlier because they
can be viewed as a filter criterion.  Even if the implementaiton of
"method" would delegate to several other methods this seems ok to me.

I still have problems with the last, very general statement, unless you
mean only slight changes in behavior by "tune": when arguments (whatever
type they have) are used to vastly change a method's behavior then a
solution with several methods is superior: it's more modular, makes life
of sub class implementors easier who may need to override just one of
these methods, those several methods are likely shorter and thus less
susceptible to errors than the all-in-one method, there is likely a
performance gain because the code that figures what to do is obsolete etc.

I think my general line here would be, that "tuning" by arguments (i.e.
small changes in behavior) is ok, but that it becomes more problematic the
greater the differences are.  There is no single measurable point that can
be used as a criterium in this case.  As always the situation at hand must
be careful evaluated to find the most appropriate solution.  It's
certainly an advantage to know both approaches and the pros and cons of
them.

Gavin, thanks for helping to sort this out!

Kind regards

    robert