Gary Wright
12/8/2005 3:44:00 AM
On Dec 7, 2005, at 9:22 PM, jonathan wrote:
> Having many terms for the same thing isn't necessarily a bad
> thing. It
> happens in every other aspect of programming as well (class methods
> are
> called 'member functions', 'methods', 'member methods', etc.).
Yes but we don't have Class#member, Class#method, Class#member_method,
Class#attribute, and Class#feature, etc. in Ruby. We have
Class#method and
that all by itself probably forces a canonical term for the concept.
I would guess that if there was no programatic way in Ruby to
reference or manipulate a singleton class then there wouldn't be such
a buzz about coming up with a standard name for it.
We have Object#class and Class#superclass which emphasize, if
not define, the canonical names for these things in Ruby. There is no
similar standard method in Ruby that returns the object generated by
the expression:
(class <<obj; self; end)
and since it is supremely awkward to type or say that expression to
refer to the concept, we all have our own habits in this regard and
only the social forces of the community to influence these habits.
I bet if you searched all the Ruby code ever written you would see
all sorts of things like:
def vclass(obj)
(class <<obj; self; end)
end
where vclass might be: meta, singleton, sclass, virtclass, eclass,
eigen,
aclass, adhoc, shadow, and so on. Everybody is coming up with their own
mnemonic for the concept because, well, you need a name if you are going
wrap up that expression in a method.
So all this is a long way of saying that what I really want for
Christmas
is a short name for (class <<obj; self; end). But if I don't get that,
I'll still be very happy with getting Ruby 1.8.4, which I will brag
about
to all my friends who are still stuck with their crufty old static
language
tools. :-)
Gary Wright