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

Discussion in 'Ruby' started by Ben Tompkins, Sep 1, 2007.

  1. Ben Tompkins

    Ben Tompkins Guest

    Ben Tompkins, Sep 1, 2007
    #1
    1. Advertising

  2. 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
    Marcin Mielżyński, Sep 1, 2007
    #2
    1. Advertising

  3. Marcin Miel=C5=BCy=C5=84ski wrote:

    > 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:
    ICQ: 205544826
    Sebastian Hungerecker, Sep 1, 2007
    #3
  4. Ben Tompkins

    Ben Tompkins Guest

    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/.
    Ben Tompkins, Sep 2, 2007
    #4
  5. Ben Tompkins

    Ben Tompkins Guest

    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 ... .'


    Sebastian Hungerecker wrote:
    > Marcin Mielżyński wrote:
    >
    >>
    >> 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
    > inherits from B, but in the latter case the singleton class does *not*
    > inherit from self, self inherits from the singleton class (well actually
    > self
    > is an instance of the singleton class, but the point is that self is
    > based on
    > the class and not the other way around), so Ben has a point when he
    > says,
    > that the arrows should point in the other direction.


    --
    Posted via http://www.ruby-forum.com/.
    Ben Tompkins, Sep 2, 2007
    #5
  6. Ben Tompkins

    Guest

    Hi --

    On Mon, 3 Sep 2007, Ben Tompkins wrote:

    > 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)
    , Sep 2, 2007
    #6
  7. Ben Tompkins

    Ben Tompkins Guest

    unknown wrote:
    > Hi --

    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








    >
    > 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


    --
    Posted via http://www.ruby-forum.com/.
    Ben Tompkins, Sep 2, 2007
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    552
    Lonnie Princehouse
    Jul 11, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    18
    Views:
    570
    Bengt Richter
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    2
    Views:
    383
    Dan Sommers
    Jul 12, 2005
  4. Replies:
    6
    Views:
    99
    Vivek
    Jan 25, 2006
  5. Ben Tompkins
    Replies:
    1
    Views:
    95
    Ben Tompkins
    Sep 1, 2007
Loading...

Share This Page