Hi --

On Mon, 2 Feb 2009, Sean O'Halpin wrote:

> On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack / rubypal.com> wrote:
>
> [snip]
>
>> But 'extend' already means something: add a module to the lookup path.
>
> Yes - to the special lookup path shared by subclasses qua instances and clones.

I'm not sure what you mean by special. Every object has only one
lookup path, and the singleton class is just placed along that path.
Do you mean the special class of singleton classes of class objects?
(The thing where their subclasses share the singleton methods.)

>> The module that gets added is a completely different object from the
>> singleton class, and you can extend an object with any number of
>> modules, anonymous or otherwise.
>
> Well, yes, that's understood :)
>
>> So there's no special identity
>> between the 'extend' operation and the singleton class.
>
> I'm not saying there's an identity - I'm saying that extend and the
> singleton class are closely related concepts.

Yes, but singleton class and non-singleton class are also closely
related. So are class and module, array and hash, integer and float...
but I wouldn't merge their terminology :-)

>>  There's a
>> relation, in the sense that obj.extend(M) is like class << obj;
>> include M; end, but I don't think there's any reason to name the
>> singleton class itself in honor of the fact that there's a method
>> called extend that operates on it, if you see what I mean.
>
> I do see what you mean. However, the relationship between #extend and
> the singleton class
> is much closer than you allow. The singleton class is the thing that's
> extended. There are no
> other methods that operate exclusively on the singleton class. In
> fact, the singleton class springs
> into existence to accommodate an extend if it's not already there.

But I wouldn't want to rename Class to IncludeClass, just because
there's an include operation especially designed for classes. I know
there's a bit more going on than that: the idea of "extending" an
object's capabilities is always present, in some form, with all this
per-object behavior in some form. But since there's already an #extend
method, I think the term is potentially too flattening, so to speak.
I'd like to be able to refer to the singleton class without seeming to
refer to the process of including modules in it, which may or may not
happen (via extend or include).

> On reading Trans' post, I was struck that extension_class, i.e. the
> site of extensions, would be a good name to unify these concepts.
> But I'd be happy with any name.

With the disclaimer that I consider there not to be a naming problem
(except for the question of whether 'singleton class' is the right
name in the class of Class objects, which grant singleton class access
to their subclass objects), I'm starting to think of 'e_class'.
Extension, extra, eigen... it's a duck-typed name :-)


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!