Rick DeNatale wrote:
> I must have missed that list of 5-6 problems, a quick re-read of the
> thread doesn't provide an obvious list, but maybe I'm just not reading
> it right.

- avoids ugliness like __send__
- reduces chances of naming conflict (CgiRequest#method, Email#send)
- allows simple pattern match to recognize present and future 
meta-programming methods (used for forwarding of non-meta methods)
- already half implemented.

ok, so that was 4, and not even all of them were problems. let's add:

- consistent naming makes methods easier to remember
- mnemonic for public vs. private interface
- avoid special keyword "class" which forces to use self.class

As Trans said, membership in a category like "metaprogramming" is not 
the basis. The basis is in the 7 points above.

> Maybe it's not a direct analogy to this thread, but the problem gets
> more serious when you try to build hierarchical categories.  Lakoff
> points out that most languages and culture agree about the most basic
> categories, rocks are rocks, trees are trees, and birds are birds. But
> when those categories get sorted into hierarchies differences emerge.

I agree that different hierarchies are possible but that doesn't mean we 
should avoid any hierarchy. Some organization is better than no 
organization. In the proposed case, metaprogramming methods are divided 
into 2 sub-hierarchies (object_* and instance_*). Might there be a 
different, orthogonal hierarchy? Yes. But that doesn't negate the 
usefulness of this one.

> I'm not sure that this "Swiss army knife" approach to design is an
> unalloyed good.

Oh, certainly not unalloyed; it's just my personal experience that when 
you have a solution for one problem (public send vs. private send) and 
then you find it happens to solve another problem (method forwarding), 
it's a good solution. And the fact that it's already half implemented 
means the pattern was already present but perhaps not conciously 
realized. Plus, it makes me feel warm and fuzzy inside :-)

Daniel