From: Ben Tompkins <nbitspoken@...>
Date: 2007-09-03T00:49:57+09:00
Subject: Re: Shouldn't it be class >> self , or am I dyslexic?

Consider the following excerpt from Programming Ruby (2nd Ed.):

***

Class Definition

class [ scope:: ] classname [ < superexpr ]
body
end

class << obj
body
end

A Ruby class definition creates or extends an object of class Class by 
executing the code in body. In the first form, a named class is created 
or extended. The resulting Class object is assigned to a constant named 
classname (see below for scoping rules). This name should start with an 
uppercase letter. In the second form, an anonymous (singleton) class is 
associated with the specific object.

***

It is only the second form that concerns us. Notice how the author makes 
no mention of inheritance, he simply states that "an anonymous 
(singleton) class is associated with the specific object." Indeed, it 
would be strange to say instead
something like "an anonymous (singleton) class is derived from the 
object" because inheritance is a relation between two classes, not an 
object and a class. It seems to me that your inheritance-based 
understanding of singleton classes replaces the author's original words 
with this bizarre, alternative explanation.

I say "strange" and "bizarre" rather than "wrong" because the 
distinction between classes and objects is somewhat blurred in Ruby, and 
especially so in the example I gave previously, where "self" is an 
instance of Class. In that context, class << self might be thought of as 
a form of dynamic inheritance
because self is a class. The problem with that thought is that it 
ignores the
semantics of the construction, which is to add behavior to the value of 
the
right-hand operand, "self," by constructing (or extending) an anonymous 
class and adding a reference to that class to the value of "self." It 
does not matter whether the singleton class is constructed or extended 
because in each case the
value of "self" does not contribute to the singleton class, it is the 
singleton class that contributes to the value of "self."

But what about: class << object, where object is not a class? As I said 
above,
calling this inheritance seems to me to stretch the notion beyond its 
proper limits. And, of course, the "semantical" objection I stated in 
the previous paragraph applies with at least as much force in this case. 
Whether the RHS is
an object or a class, the effect of the operation is to introduce new 
functionality via the LHS and add it to the RHS, which is why the arrows 
should point toward the RHS.

nbits






Marcin Mielży�?ski wrote:
> Ben Tompkins pisze:
>> This is the correct title, uh, I think...
>> 
>> dyslexic me :)
> 
> The << direction is correct (and intuitive IMHO), given:
> 
> class A < B
> end
> 
> This can do two things, either creates and opens class A extending class
> B or reopens class A if it already exits (in the second case the
> superclass is optional, but if given it must match the existing class
> superclass)
> 
> 
> now, given:
> 
> s = "some_string"
> 
> class << s
> end
> 
> What this does ? it either creates and opens singleton class for s
> instance or reopens the singleton it if it already exits. Since
> singleton classes dont have their names you could also imagine
> <anonyous_name> between class and << tokens here.
> 
> The only question that could arise is: why there are two different
> tokens (<< and <) ?. I think Matz wanted to syntactically differentiate
> how to deal with classes and metaclasses.
> 
> lopex

-- 
Posted via http://www.ruby-forum.com/.