Call functions of superclass

ruby-talk
41

Hi --

Hello,

No; it will point to the superclass of the class of self :slight_smile:

   class C
   end
   class D < C
   end
   D.new.class.superclass # C

I think we are using different terminology. Take a look at this code:

class A
def A.hi
   puts "A.hi"
end

def hi
   puts "hi"
end
end

class B < A
def hi
   self.class.superclass.hi
end
end

b = B.new
b.hi

This will output

A.hi

Yes, because B.new.class.superclass is A, and A responds to "hi". The
method A.hi is defined in A's singleton class (or "metaclass") -- but
the object to which you are sending the message "hi" is A, not A's
singleton class.

In "Programming Ruby", they define the "metaclass" as the object which
contains the class-wide objects of the class. IE, the metaclass of A would
contain A.hi, and not A#hi (I could be getting the notation of A.hi and
A#hi backwards, or completely wrong -- A.hi is the class method, and A#hi
is the instance method.)

Therefore, in B#hi, self.class.superclass does not refer to the superclass
of B -- rather it refers to the metaclass of the super of B. If it pointed
to the superclass of B, then calling

self.class.superclass.hi

would print "hi", instead of "A.hi"

No, because A is the superclass of the class of "self" in your
example. A is an object in its own right; it responds to "hi".

I think you're adding an extra level of reference or indirection or
something. Look at this:

irb(main):001:0> class C; object_id; end
=> 1615634
irb(main):002:0> C.new.class.object_id
=> 1615634
irb(main):003:0> C.new.class.superclass.object_id
=> 1683084
irb(main):004:0> C.new.class.superclass
=> Object
irb(main):005:0> Object.object_id
=> 1683084
irb(main):006:0> class << C; object_id; end
=> 1615554

As you can see, the singleton class of C is not the same object as
either C or the class of C.

("Singleton class" is the most general term; the Pickaxe uses
"metaclass" to mean singleton class of a Class object. I tend to just
use "singleton".)

David

···

On Thu, 24 Aug 2006, Nathan Smith wrote:

On Thu, 24 Aug 2006 dblack@wobblini.net wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
Ruby for Rails => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

42

Um. Me. That would totally rock.

  def foo
    blah
    my_block = current_block if block_given?
  end

That would mean that I wouldn't need block boxing unless that path was
taken in code.

-austin

···

On 8/25/06, Christian Neukirchen <chneukirchen@gmail.com> wrote:

While we are at adding methods, who else would like ot have a method
that returns the current block, so you can access it without needing
to declare it in the arguments list? (And likewise for lambda{}, even
if 1.9 fixes that.)

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

43

Like Proc.new ?
IIRC there were plans to deprecate it in 1.9, so that request seems to go
against the tide of change :slight_smile: (but it still seems to work, though):

RUBY_VERSION # => "1.8.5"
RUBY_RELEASE_DATE # => "2006-08-25"
def a; Proc.new.call end
a {1+1} # => 2

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
def a; Proc.new.call end
a{1+1} # => 2

···

On Fri, Aug 25, 2006 at 06:51:45PM +0900, Christian Neukirchen wrote:

While we are at adding methods, who else would like ot have a method
that returns the current block, so you can access it without needing
to declare it in the arguments list? (And likewise for lambda{}, even
if 1.9 fixes that.)

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby

44

Hi --

At the very least, 'singleton_class' is too long. Just 'singleton'
would suffice.

Alas, I wish we could just go back to 'metaclass'.

It's probably my Smalltalk background, but metaclass bothers me as a
name for a singleton class which holds INSTANCE specific methods for a
non-class.

On the other hand, metaclass fits perfectly in my mind for naming a
singleton class of a CLASS which holds the class methods for that
class.

The fact that in the ruby implementation, both of these are singleton
classes is an accident of implementation (in the sense of accidental
being the antonym of essential).

But it's very characteristic of Ruby. There are rather few special
cases. Objects have singleton classes (most objects, anyway); classes
are objects; therefore, classes have singleton classes. It's
interesting to me how little the language cares, so to speak, whether
we as its users decide to name the singleton classes of classes
'metaclasses', or the singleton methods of classes 'class methods'.
We're free to do that, but at the language level the model is
consistent as between classes and other objects.

(Singleton classes of classes are a bit special-cased -- in the sense
that they become each other's superclasses -- but for the most part,
classes behave as "civilians" when it comes to the singleton
mechanisms.)

Now if I might dredge up some
Smalltalk terminology, I might suggest that we call:

  The singleton class of an instance its 'behavior' and

What would you then call its behavior? :slight_smile: (i.e., the way it behaves) I can't comment on the Smalltalk aspect of the terminology, but I
don't think it's a good fit for Ruby singleton classes. If I have an
object obj, I don't think the phrase "obj's behavior" conjures up its
singleton class.

  The singleton class of a class its 'metaclass.'

Classes are about representing a 'class' of instances: instantiating
them and providing common behavior.

That's the thing.... An object's 'behavior' is not uniquely
determined by its singleton class, so I wouldn't want to start trying
to use that word to describe the singleton class.

David

···

On Sat, 26 Aug 2006, Rick DeNatale wrote:

On 8/25/06, Trans <transfire@gmail.com> wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
Ruby for Rails => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

45

>
> Justin Bailey wrote:
>>>
>>>>
>>>>> # Sigh -- Matz, *please* can we have this? :slight_smile:
>>>>> def singleton_class
>>>>> class << self; self; end
>>>>> end
>>
>> +100 - please give us singleton_class!
>>
>>>
>>> much better, imho, and used all over my own code is
>>>
>>> def singleton_class &b
>>> sc = class << self; self; end
>>> b ? sc.module_eval &b : sc
>>> end
>>>
>>> obj = Object.new
>>
>> +1 to this implementation.
>
> At the very least, 'singleton_class' is too long. Just 'singleton'
> would suffice.
>
> Alas, I wish we could just go back to 'metaclass'.

i too would like a shorter namer, but singleton_class is in the source and has
been for years. momentum! :wink:

So what wrong with just #singleton? That would be more reasible for
things like: 'singleton_class.module_eval' and
'singleton_class.class_eval', which would instead read simply:

  singleton.module_eval
  singleton.class_eval

seriously though - the name comes up in google - and we all know how important
that it for newbies!

Yeh. I relent.

T.

···

ara.t.howard@noaa.gov wrote:

On Fri, 25 Aug 2006, Trans wrote:
>> On 8/23/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>>> On Thu, 24 Aug 2006, James Edward Gray II wrote:
>>>> On Aug 23, 2006, at 3:13 PM, dblack@wobblini.net wrote:

46

> Therefore, in B#hi, self.class.superclass does not refer to the superclass
> of B -- rather it refers to the metaclass of the super of B. If it pointed

no, not really. self.class.superclass make reference to the superclass of
B

It refers to the metaclass of the superclass of B -- see Programming Ruby
pp. 380-381.

> to the superclass of B, then calling

> self.class.superclass.hi

> would print "hi", instead of "A.hi"

no, if self.class.superclass == A then self.class.superclass.hi is the
same than A.hi, and ruby will print "A.hi"

Inside of a class instance method, self.class returns a reference to the
metaclass of the class. Calling superclass on the metaclass returns
another metaclass, and you're right -- it will print A.hi (as I said =])

Nate

···

On Fri, 25 Aug 2006, ts wrote:

47

I concede your point -- I was using singleton as the object-specific
class, while it is the opposite of that. Thanks for the clarification.
Maybe now my arguments will make more sense!

Nate

···

On Fri, 25 Aug 2006 dblack@wobblini.net wrote:

Hi --

On Thu, 24 Aug 2006, Nathan Smith wrote:

> Hello,
>
> On Thu, 24 Aug 2006 dblack@wobblini.net wrote:
>
>> No; it will point to the superclass of the class of self :slight_smile:
>>
>> class C
>> end
>> class D < C
>> end
>> D.new.class.superclass # C
>
>
> I think we are using different terminology. Take a look at this code:
>
> class A
> def A.hi
> puts "A.hi"
> end
>
> def hi
> puts "hi"
> end
> end
>
> class B < A
> def hi
> self.class.superclass.hi
> end
> end
>
> b = B.new
> b.hi
>
>
> This will output
>
> A.hi

Yes, because B.new.class.superclass is A, and A responds to "hi". The
method A.hi is defined in A's singleton class (or "metaclass") -- but
the object to which you are sending the message "hi" is A, not A's
singleton class.

> In "Programming Ruby", they define the "metaclass" as the object which
> contains the class-wide objects of the class. IE, the metaclass of A would
> contain A.hi, and not A#hi (I could be getting the notation of A.hi and
> A#hi backwards, or completely wrong -- A.hi is the class method, and A#hi
> is the instance method.)
>
> Therefore, in B#hi, self.class.superclass does not refer to the superclass
> of B -- rather it refers to the metaclass of the super of B. If it pointed
> to the superclass of B, then calling
>
> self.class.superclass.hi
>
> would print "hi", instead of "A.hi"

No, because A is the superclass of the class of "self" in your
example. A is an object in its own right; it responds to "hi".

I think you're adding an extra level of reference or indirection or
something. Look at this:

irb(main):001:0> class C; object_id; end
=> 1615634
irb(main):002:0> C.new.class.object_id
=> 1615634
irb(main):003:0> C.new.class.superclass.object_id
=> 1683084
irb(main):004:0> C.new.class.superclass
=> Object
irb(main):005:0> Object.object_id
=> 1683084
irb(main):006:0> class << C; object_id; end
=> 1615554

As you can see, the singleton class of C is not the same object as
either C or the class of C.

("Singleton class" is the most general term; the Pickaxe uses
"metaclass" to mean singleton class of a Class object. I tend to just
use "singleton".)

48

  def foo
    blah
    blah
    my_block = current_block if block_given?

moulon% cat b.rb
#!/usr/bin/ruby
def blah
end

def foo
   blah
   blah
   my_block = Proc.new if block_given?
   p my_block
end

foo
foo {}
moulon%

moulon% ./b.rb
nil
#<Proc:0x00000000@./b.rb:13>
moulon%

Guy Decoux

49

i use

   harp:~ > cat a.rb
   def foo()
     b = lambda{|*a| yield *a} if block_given?
     b[42] if b
   end

   foo
   foo{|n| p n}

   harp:~ > ruby a.rb
   42

-a

···

On Fri, 25 Aug 2006, Mauricio Fernandez wrote:

On Fri, Aug 25, 2006 at 06:51:45PM +0900, Christian Neukirchen wrote:

While we are at adding methods, who else would like ot have a method
that returns the current block, so you can access it without needing
to declare it in the arguments list? (And likewise for lambda{}, even
if 1.9 fixes that.)

Like Proc.new ?
IIRC there were plans to deprecate it in 1.9, so that request seems to go
against the tide of change :slight_smile: (but it still seems to work, though):

RUBY_VERSION # => "1.8.5"
RUBY_RELEASE_DATE # => "2006-08-25"
def a; Proc.new.call end
a {1+1} # => 2

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
def a; Proc.new.call end
a{1+1} # => 2

--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dalai lama

50

Inside of a class instance method, self.class returns a reference to the
metaclass of the class. Calling superclass on the metaclass returns
another metaclass, and you're right -- it will print A.hi (as I said =])

re read your example

class B < A
  def hi
   self.class.superclass.hi
end
end

moulon% cat b.rb
#!/usr/bin/ruby
class A
end

class B < A
   def hi
      p self.class
      p class << self.class; self end
   end
end

B.new.hi
moulon%

moulon% ./b.rb
B
#<Class:B>
moulon%

You really think that self.class, i.e. B, make reference to the singleton
class of B ?

Guy Decoux

51

<snip>

I concede your point -- I was using singleton as the object-specific
class, while it is the opposite of that. Thanks for the clarification.
Maybe now my arguments will make more sense!

In any case, my original "want" stands, in that super be treated as an
object, and not just a keyword which facilitates a certain type of method
calling.

Nate

···

On Fri, 25 Aug 2006, Nathan Smith wrote:

On Fri, 25 Aug 2006 dblack@wobblini.net wrote:

52

Hi --

I think you're adding an extra level of reference or indirection or
something. Look at this:

irb(main):001:0> class C; object_id; end
=> 1615634
irb(main):002:0> C.new.class.object_id
=> 1615634
irb(main):003:0> C.new.class.superclass.object_id
=> 1683084
irb(main):004:0> C.new.class.superclass
=> Object
irb(main):005:0> Object.object_id
=> 1683084
irb(main):006:0> class << C; object_id; end
=> 1615554

As you can see, the singleton class of C is not the same object as
either C or the class of C.

("Singleton class" is the most general term; the Pickaxe uses
"metaclass" to mean singleton class of a Class object. I tend to just
use "singleton".)

I concede your point -- I was using singleton as the object-specific
class, while it is the opposite of that. Thanks for the clarification.
Maybe now my arguments will make more sense!

It doesn't sound like I clarified it.... :slight_smile: The singleton class *is*
the object-specific class. Here's a common idiom that illustrates it:

   class Object
     def singleton_class
       class << self
         self
       end
     end
   end

It sounds like this came out backwards -- ?

David

···

On Fri, 25 Aug 2006, Nathan Smith wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
Ruby for Rails => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

53

Cool. I didn't know that.

-austin

···

On 8/25/06, ts <decoux@moulon.inra.fr> wrote:

moulon% cat b.rb
#!/usr/bin/ruby
def blah
end

def foo
   blah
   my_block = Proc.new if block_given?
   p my_block
end

foo
foo {}
moulon%

moulon% ./b.rb
nil
#<Proc:0x00000000@./b.rb:13>
moulon%

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

54

ts <decoux@moulon.inra.fr> writes:

> def foo
> blah
> blah
> my_block = current_block if block_given?

moulon% cat b.rb
#!/usr/bin/ruby
def blah
end

def foo
   blah
   blah
   my_block = Proc.new if block_given?
   p my_block
end

foo
foo {}
moulon%

moulon% ./b.rb
nil
#<Proc:0x00000000@./b.rb:13>
moulon%

Whoa! Thanks!

···

Guy Decoux

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

55

> Inside of a class instance method, self.class returns a reference to the
> metaclass of the class. Calling superclass on the metaclass returns
> another metaclass, and you're right -- it will print A.hi (as I said =])

<snip>

Guy Decoux

You really think that self.class, i.e. B, make reference to the singleton
class of B ?

Re-read what I wrote:

> Inside of a class instance method, self.class returns a reference to

the metaclass of the class.

metaclass != singleton class

Nate

···

On Fri, 25 Aug 2006, ts wrote:

56

Der. OK, I take back my concedation. Let's drop this thing. Requiring way
too much effort to get nowhere.

Nate

···

On Fri, 25 Aug 2006 dblack@wobblini.net wrote:

Hi --

On Fri, 25 Aug 2006, Nathan Smith wrote:

>> I think you're adding an extra level of reference or indirection or
>> something. Look at this:
>>
>> irb(main):001:0> class C; object_id; end
>> => 1615634
>> irb(main):002:0> C.new.class.object_id
>> => 1615634
>> irb(main):003:0> C.new.class.superclass.object_id
>> => 1683084
>> irb(main):004:0> C.new.class.superclass
>> => Object
>> irb(main):005:0> Object.object_id
>> => 1683084
>> irb(main):006:0> class << C; object_id; end
>> => 1615554
>>
>> As you can see, the singleton class of C is not the same object as
>> either C or the class of C.
>>
>> ("Singleton class" is the most general term; the Pickaxe uses
>> "metaclass" to mean singleton class of a Class object. I tend to just
>> use "singleton".)
>
> I concede your point -- I was using singleton as the object-specific
> class, while it is the opposite of that. Thanks for the clarification.
> Maybe now my arguments will make more sense!

It doesn't sound like I clarified it.... :slight_smile: The singleton class *is*
the object-specific class. Here's a common idiom that illustrates it:

   class Object
     def singleton_class
       class << self
         self
       end
     end
   end

It sounds like this came out backwards -- ?

57

metaclass != singleton class

Well, it's well known : metaclass exist in Smalltalk, singleton class in
ruby. Nothing new :slight_smile:

Guy Decoux

58

That's great. Thanks for the info :wink: I'm referring to metaclass as stated
in Programming Ruby, not smalltalk.

Nate

···

On Fri, 25 Aug 2006, ts wrote:

> metaclass != singleton class

Well, it's well known : metaclass exist in Smalltalk, singleton class in
ruby. Nothing new :slight_smile:

59

The difference's between Ruby and Smalltalk here are subtle, and
somewhat just terminology.

In both Smalltalk and Ruby, classes hold the methods of their
instances, and classes themselves must have a 'class' to hold any
class methods, which are really instance methods of the object which
represents the class.

The difference is that Ruby and Smalltalk factor things a little differently.

In Smalltalk all classes are ultimately subclasses of Class. If I
recall correctly the class Class provides the base methods for making
subclasses, since in Smalltak subclasses are created by sending a
message to the superclass. In Ruby subclass definition is done
syntactically as part of eval. In Smalltalk there is a class called
Metaclass, from which all of the classes of classes descend. The
common superclass of both Class and Metaclass is Behavior which
provides the methods involved with holding methods. To some extent
the Module class in Ruby serves some of the purposes of Behavior in
Smalltalk, although Smalltalk doesn't have the concepts of name
scoping and implementation mixing which the Ruby Module provides.

And touching on the theme of this particular thread, there's been some
confusion about just what super means. It's not really a 'reference'
to the superclass of self in a method, it's a 'reference' to the
superclass of the class which contains the method, which may well be a
superclass of the class of self. In both Smalltalk and Ruby, the
objects which contain methods i.e descendants of Behavior in
Smalltalk, or Module in Ruby, act as nodes in a tree which is searched
for methods when they are invoked. Normally when a message is sent to
an object, the search starts in that object's class, and goes up the
superclass chain until it is found, or if the chain runs out, the
bailout method is called instead, method_missing in Ruby, or
doesNotUnderstand: in Smalltalk. In both Ruby and Smalltalk, super is
a syntactic construct which causes the search to start just above the
point where the current method was found.

One aspect of Smalltalk which I miss in Ruby is that it provided
deeper reflection, not just at the class level, but also at the method
level. Smalltalk method objects can do things like enumerate the
messages they send, which is very useful in developing an IDE.

Matz is reluctant to call the class of a Ruby class a metaclass,
although it serves much of the same purpose in Ruby as a Smalltalk
Metaclass. Since Ruby already has singleton classes to provide
instance-specific behavior, another way of thinking about classes of
classes in Ruby is as singleton classes of classes, which seems to be
Matz's preferred way of viewing them. One difference is that instance
singletons aren't created until they are needed, while the class of a
class is created along with the class.

I'm pretty sure that the delay in creating a 'class' for instance
behavior is why they are called singleton classes, in effect a
singleton pattern is used to ensure that a given instance has at most
one class to hold it's instance specific behavior.

I had been thinking that the class of a class in Ruby could also be
lazily constructed, but in typing this note, I realized that they need
to be instantiated along with a new class because there needs to be a
place to start looking for methods when a message is sent to a class.
I guess an alternate implementation in Ruby might have been to make
the intial class of a new class, the class of it's first superclass
which had one, and then change that when class methods were added, but
I suspect that such an implementation would be messier than the simple
expedient of just creating an empty meta/singleton class.

Sorry for the long post. I've been working on something for my blog
on this very topic for about two weeks, and this chain of
consciousness just started pouring out.. I guess I'll store it away as
fodder for that article.

···

On 8/24/06, ts <decoux@moulon.inra.fr> wrote:

> metaclass != singleton class

Well, it's well known : metaclass exist in Smalltalk, singleton class in
ruby. Nothing new :slight_smile:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

60

That's great. Thanks for the info :wink: I'm referring to metaclass as stated
in Programming Ruby, not smalltalk.

Re read carefully "Programming Ruby", it was written by someone which know
ruby better than you ...

Guy Decoux