On Mar 5, 3:17 pm, "David A. Black" <dbl... / wobblini.net> wrote:
> Have another look at the thread. Daniel was adducing
> metaprogramming-ness as a reason for naming methods a certain way, not
> something that happens to be the case.  I was discussing this and
> expressing misgivings about that approach.

Yes he was, but as a consequence of other needs, not just because
there is such a category. So that my point: any argument against doing
this based on the fact that it's a catagorization, I feel is missing
the point. No other cataegories are being considered. It's not about a
general pattern of naming methods according to categories. Rather it's
one paticular set of methods that have some special needs/uses that
would be better served by a consistant naming pattern.

> In any case, you're talking about metaprogramming operations *on*
> method names (removing them, using method_missing), which is different
> from the matter of naming methods because what those methods do is
> metaprogramming.

Yes, exactly. And I think this is what Daniel really meant too.

> I think that, too, is a tricky road to travel.  I'd
> rather see each method have the best possible name, since it's going
> to be used more as a method than as a string to be matched for method
> removal purposes and so forth.

Well, what is best? That's the very question. Figuring out what is
best means taking into account all the uses. Yes, plain usage is
important, so we don't really want methods that are too long or
esoteric. Is that the criteria you are using? Yet there are other
important considerations. An important one being that "meta" methods
be  easily discernable so they can be readuly worked around in
delegators --and delegators are very common in OOP. To me it's just a
big bonus that this works out to a pattern that is already largely
(subconsciously?) followed in Ruby, namely using the prefixes object_
and instance_, and consequently brings all the benefits of quick
recognition and eased learning. So again, what is best?

> Moreover, it's very hard to predict
> exactly which batch of methods someone is going to want to remove;
> they may or may not all fall into a secondary category like
> metaprogramming.

It's quite easy really. Most of the time it's the same ones' b/c most
of the time is for delegation. And in a case of numerous exeptions,
we'd be no worse off then we were before anyway. Surely you must see
that?

T.