Shouldn't it be class >> self , or am I dyslexic?

M

Marcin Mielżyński

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
 
S

Sebastian Hungerecker

Marcin said:
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=20
[...]
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.

Yes, but there is a major difference between those two. In the former case =
A=20
inherits from B, but in the latter case the singleton class does *not*=20
inherit from self, self inherits from the singleton class (well actually se=
lf=20
is an instance of the singleton class, but the point is that self is based =
on=20
the class and not the other way around), so Ben has a point when he says,=20
that the arrows should point in the other direction.


=2D-=20
NP: Iron Maiden - The Clairvoyant
Jabber: (e-mail address removed)
ICQ: 205544826
 
B

Ben Tompkins

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
 
B

Ben Tompkins

I like it when people agree with me, and according to the diagram on
page 384 of Programming Ruby, you are basically correct to say that
"self inherits from the singleton class." The diagram shows that a
"virtual" (singleton) class is inserted into the inheritance hierarchy
for self (or whatever the RHS happens to be) as an immediate subclass of
the most derived, non-singleton, class of which the RHS is an instance
whenever 'class << RHS ...' is executed. So even if we think of the '<<'
as an "inheritance operator," it is still pointing in the wrong
direction! But is inheritance really the right concept here? Notice that
the singleton class is inserted below the most specific class of the RHS
term. If the RHS were the same as its class (which is impossible), then
Marcin would be right, because the singleton class would be subclassing
the RHS. But no instance is ever the same as its class. What is really
going on is that we are
augmenting the interface of the RHS by decorating its most derived class
with an anonymous class to which RHS has exclusive access, thus
effectively adding the methods of the singleton class to the RHS. As the
recipient of these new methods, RHS is on the receiving side of the
operation, which is why 'class >> RHS ...' is more intuitive than 'class
<< RHS ... .'
 
D

dblack

Hi --

I like it when people agree with me, and according to the diagram on
page 384 of Programming Ruby, you are basically correct to say that
"self inherits from the singleton class." The diagram shows that a
"virtual" (singleton) class is inserted into the inheritance hierarchy
for self (or whatever the RHS happens to be) as an immediate subclass of
the most derived, non-singleton, class of which the RHS is an instance
whenever 'class << RHS ...' is executed. So even if we think of the '<<'
as an "inheritance operator," it is still pointing in the wrong
direction! But is inheritance really the right concept here? Notice that
the singleton class is inserted below the most specific class of the RHS
term. If the RHS were the same as its class (which is impossible), then
Marcin would be right, because the singleton class would be subclassing
the RHS. But no instance is ever the same as its class. What is really
going on is that we are
augmenting the interface of the RHS by decorating its most derived class
with an anonymous class to which RHS has exclusive access, thus
effectively adding the methods of the singleton class to the RHS. As the
recipient of these new methods, RHS is on the receiving side of the
operation, which is why 'class >> RHS ...' is more intuitive than 'class
<< RHS ... .'

I'm sorry, but I had to chuckle at the use of the word "intuitive"
after that explanation :)

I wouldn't think of class << obj as having anything at all to do with
inheritance. It's more like this, in terms of how the class keyword
works:

class expr

where expr can be:

A
A < B
<< arbitrary_object

So the inheritance < is more like:

class (A < B)

and the singleton notation is more like:

class (<< obj)

Remember, also, that the class keyword isn't itself a class
identifier; you're not looking for "the class that is >> object", but
the class that is, so to speak, yielded from object. (Or something.)
It's not a notation that relates very closely to any other.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
B

Ben Tompkins

unknown said:
Perhaps you were misled by the first sentence of my reply to Sebastian,
in which
I said 'you are basically correct to say that "self inherits from the
singleton class.".' Note the "basically" qualification. Apart from that
sentence, my entire exposition prior to this reply, which spans two
postings, argues *against* the idea that "<<" signifies inheritance in:

class << object
...
end

In pseudocode, this translates into:

object.method1 # error
object.method2 # error

1. temp = Class.new { method1, method2, ... }
2. temp.superclass = object.class
3. object.class = temp

object.method1 # OK
object.method2 # OK

Thus 1-3 might be more succinctly expressed as:

Class.new { method1, method2 } >> object

which is very close to:

class >> object # instead of class << object
def method1
...
end

def method2
...
end
end

Got it?

nbits
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top