Call functions of superclass

David_A_Black3 · 23 August 2006 20:13

Hi --

I think he's wanting to know if it's possible to call a different method
of the superclass than the method that the interpreter is in.

I'm not sure it's a great idea, but sure you can:

def send_super(meth, *args, &blk)
  # hide current method
  if self.class.instance_methods(false).include? meth.to_s
    self.class.send(:alias_method, :_hidden, meth)
    self.class.send(:remove_method, meth)
  end

  send(meth, *args, &blk)
ensure
  self.class.send(:alias_method, meth, :_hidden) if methods.include? "_hidden"
end

wow, that's way too much work (plus thread-unsafe).

def send_super(meth, *args, &b)
self.class.superclass.instance_method(meth).bind(self).call(*args, &b)
end

RUBY_VERSION # => "1.8.5"
RUBY_RELEASE_DATE # => "2006-07-07"
class Parent
def a
   "Hello from Parent!"
end
end

class Child < Parent
def a
   "Hello from Child!"
end

def b
   send_super(:a)
end
end

child = Child.new
puts child.b
puts child.a

__END__
# >> Hello from Parent!
# >> Hello from Child!

This only works for superclasses, I think, whereas super just looks
higher up in the method lookup chain, in modules as well as classes.

I'm thinking of, for example:

class A
   def x
     puts "A#x"
   end
end

module M
   def x
     puts "M#x"
   end
   def y
     send_super(:x)
   end
end

a = A.new
a.extend(M)

a.x
a.y

So... maybe this:

# Sigh -- Matz, *please* can we have this?
def singleton_class
class << self; self; end
end

def send_super(meth, *args, &b)
m = singleton_class.ancestors[1..-1].find {|a| a.instance_methods(false).include?(meth.to_s)}
m.instance_method(meth).bind(self).call(*args, &b)
end

David

···

On Thu, 24 Aug 2006, Mauricio Fernandez wrote:

On Thu, Aug 24, 2006 at 01:45:40AM +0900, James Edward Gray II wrote:

On Aug 23, 2006, at 11:11 AM, 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.

Julian_Julik_Tarkhan · 23 August 2006 21:41

I am not saying I _need_ to do that, I was curious if it's at all possible. It is in PHP for instance (in Python too AFAIK).

···

On 23-aug-2006, at 18:43, William Crawford wrote:

Douglas A. Seifert wrote:

Why would you need to explicitly reference super? It is not necessary:

He has redefined the 'another' method in the child class. But for some
reason, he needs the 'another' method in the parent class instead.

--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl

Julian_Julik_Tarkhan · 26 August 2006 04:22

Don't know if my response went through but I wanted to say that this rocks now I can rest and know that "I can shall the need arise".

Doing the above for classes/modules/foos is close but not essential :-))

···

On 23-aug-2006, at 20:01, Mauricio Fernandez wrote:

wow, that's way too much work (plus thread-unsafe).

def send_super(meth, *args, &b)
self.class.superclass.instance_method(meth).bind(self).call(*args, &b)
end

--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl

Nate_Smith2 · 23 August 2006 20:22

Exactly! That's the point I was getting at. It'd be nice if this would
work. "self" points to the object who's method the interpreter is in, so
playing by that same game, "super" should point to the superclass of the
object who's method the interpreter is in.

Nate

···

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

Hi --

On Thu, 24 Aug 2006, Nathan Smith wrote:

> On Thu, 24 Aug 2006, Douglas A. Seifert wrote:
>
>> Why would you need to explicitly reference super? It is not necessary:
>>
>> $ irb
>> irb(main):001:0> class Parent
>> irb(main):002:1> def zoo
>> irb(main):003:2> puts "zoo in Parent!"
>> irb(main):004:2> end
>> irb(main):005:1> end
>> => nil
>> irb(main):006:0>
>> irb(main):007:0* class Child < Parent
>> irb(main):008:1> def hoo
>> irb(main):009:2> zoo
>> irb(main):010:2> end
>> irb(main):011:1> end
>> => nil
>> irb(main):013:0> c = Child.new
>> => #<Child:0x39dd78>
>> irb(main):014:0> c.hoo
>> zoo in Parent!
>> => nil
>> irb(main):015:0>
>
> Better example:
>
> class Child < Parent
> def hoo
> super.zoo
> end
> def zoo
> print "don't want to be here"
> end
> end

But the Parent class has no hoo instance method, so calling super from
hoo won't work.

James_Edward_Gray_II · 23 August 2006 20:26

I have never before given my opinion on this issue, so I think I'll take this chance to do so. After this message, I promise to shut up about it.

I agree that singleton_class() should be added to the language.

Here's the pros and cons as I understand them:

Pros

···

On Aug 23, 2006, at 3:13 PM, dblack@wobblini.net wrote:

# Sigh -- Matz, *please* can we have this?
def singleton_class
class << self; self; end
end

====

* Internally, this is what Ruby calls the class in question
* The C API uses this name all over the place
* Documentation and many books refer to the class as such
* Matz's use of the term predates the design pattern usage
* Anyone learning singleton class functionality is smart enough to
keep it straight from the design pattern of the same name
* None of the other suggestions seems to have won over the masses
* We would have an official name to refer to this concept

Cons

* It conflicts with a popular design pattern

To me, the choice is pretty obvious. It's not like it's the first overloaded term in computing history or anything.

OK, I've said my peace. Thanks for listening.

James Edward Gray II

Ara.T.Howard6 · 23 August 2006 20:31

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

obj.singleton_class{ def foo() 42 end }

2 cts.

-a

···

On Thu, 24 Aug 2006, James Edward Gray II wrote:

On Aug 23, 2006, at 3:13 PM, dblack@wobblini.net wrote:

# Sigh -- Matz, *please* can we have this?
def singleton_class
class << self; self; end
end

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

David_A_Black3 · 23 August 2006 20:58

Hi --

···

On Thu, 24 Aug 2006, Nathan Smith wrote:

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

Hi --

On Thu, 24 Aug 2006, Nathan Smith wrote:

On Thu, 24 Aug 2006, Douglas A. Seifert wrote:

Why would you need to explicitly reference super? It is not necessary:

$ irb
irb(main):001:0> class Parent
irb(main):002:1> def zoo
irb(main):003:2> puts "zoo in Parent!"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0>
irb(main):007:0* class Child < Parent
irb(main):008:1> def hoo
irb(main):009:2> zoo
irb(main):010:2> end
irb(main):011:1> end
=> nil
irb(main):013:0> c = Child.new
=> #<Child:0x39dd78>
irb(main):014:0> c.hoo
zoo in Parent!
=> nil
irb(main):015:0>

Better example:

class Child < Parent
def hoo
super.zoo
end
def zoo
print "don't want to be here"
end
end

But the Parent class has no hoo instance method, so calling super from
hoo won't work.

Exactly! That's the point I was getting at. It'd be nice if this would
work. "self" points to the object who's method the interpreter is in, so
playing by that same game, "super" should point to the superclass of the
object who's method the interpreter is in.

It depends what you mean by "should" I think the current behavior
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.

David

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

Justin_Bailey · 23 August 2006 20:49

>
>> # Sigh -- Matz, *please* can we have this?
>> 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.

···

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:

Nate_Smith2 · 23 August 2006 21:38

If I'm thinking correctly, self.class.superclass will point to the
metaclass of the superclass of self. This isn't what is wanted when
calling super.someMethod (that would be like doing
super.class.someMethod, which is different). I recognize Ruby is different
from other langauges, but many other languages (even less OO capable
languages such as Java and C++) have the use of the "super.someMethod"
functionality.

Nate

···

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

Hi --

On Thu, 24 Aug 2006, Nathan Smith wrote:

> On Thu, 24 Aug 2006 dblack@wobblini.net wrote:
>
>> Hi --
>>
>> On Thu, 24 Aug 2006, Nathan Smith wrote:
>>
>>> On Thu, 24 Aug 2006, Douglas A. Seifert wrote:
>>>
>>>> Why would you need to explicitly reference super? It is not necessary:
>>>>
>>>> $ irb
>>>> irb(main):001:0> class Parent
>>>> irb(main):002:1> def zoo
>>>> irb(main):003:2> puts "zoo in Parent!"
>>>> irb(main):004:2> end
>>>> irb(main):005:1> end
>>>> => nil
>>>> irb(main):006:0>
>>>> irb(main):007:0* class Child < Parent
>>>> irb(main):008:1> def hoo
>>>> irb(main):009:2> zoo
>>>> irb(main):010:2> end
>>>> irb(main):011:1> end
>>>> => nil
>>>> irb(main):013:0> c = Child.new
>>>> => #<Child:0x39dd78>
>>>> irb(main):014:0> c.hoo
>>>> zoo in Parent!
>>>> => nil
>>>> irb(main):015:0>
>>>
>>> Better example:
>>>
>>> class Child < Parent
>>> def hoo
>>> super.zoo
>>> end
>>> def zoo
>>> print "don't want to be here"
>>> end
>>> end
>>
>> But the Parent class has no hoo instance method, so calling super from
>> hoo won't work.
>
> Exactly! That's the point I was getting at. It'd be nice if this would
> work. "self" points to the object who's method the interpreter is in, so
> playing by that same game, "super" should point to the superclass of the
> object who's method the interpreter is in.

It depends what you mean by "should" I think the current behavior
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.

David_A_Black3 · 25 August 2006 09:59

Hi --

# Sigh -- Matz, *please* can we have this?
def singleton_class
  class << self; self; end
end

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

obj.singleton_class{ def foo() 42 end }

I'd rather not see module_eval wrapped/hidden in singleton_class. I
see singleton_class as a kind of twin method with class. In part I'm
hoping for this because I think it will make it vastly easier for
people to understand the basic premise that an object has a [birth]
class and a singleton class, from both of which it draws its
behaviors. I don't see an advantage to adding a special twist to
singleton_class. If it gives you a class object, you can always call
module_eval on that, as with any class object.

David

···

On Thu, 24 Aug 2006, 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:

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

David_A_Black3 · 23 August 2006 21:54

Hi --

Hi --

Hi --

Why would you need to explicitly reference super? It is not necessary:

$ irb
irb(main):001:0> class Parent
irb(main):002:1> def zoo
irb(main):003:2> puts "zoo in Parent!"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0>
irb(main):007:0* class Child < Parent
irb(main):008:1> def hoo
irb(main):009:2> zoo
irb(main):010:2> end
irb(main):011:1> end
=> nil
irb(main):013:0> c = Child.new
=> #<Child:0x39dd78>
irb(main):014:0> c.hoo
zoo in Parent!
=> nil
irb(main):015:0>

Better example:

class Child < Parent
def hoo
super.zoo
end
def zoo
print "don't want to be here"
end
end

But the Parent class has no hoo instance method, so calling super from
hoo won't work.

Exactly! That's the point I was getting at. It'd be nice if this would
work. "self" points to the object who's method the interpreter is in, so
playing by that same game, "super" should point to the superclass of the
object who's method the interpreter is in.

It depends what you mean by "should" I think the current behavior
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.

If I'm thinking correctly, self.class.superclass will point to the
metaclass of the superclass of self.

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

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

This isn't what is wanted when calling super.someMethod (that would
be like doing super.class.someMethod, which is different). I
recognize Ruby is different from other langauges, but many other
languages (even less OO capable languages such as Java and C++) have
the use of the "super.someMethod" functionality.

Well... it's probably good that Ruby isn't a superset of those less OO
capable languages But I'm getting confused by the use of an
existing keyword to describe a new concept. Also, it's not clear what
the keyword would actually produce. You're sending the someMethod
message to it, but from what I understand you don't really mean it to
respond to that method, but rather to re-send the message to the
current self, using the constraint that the currently visible version
of the method be skipped.

I wondering whether perhaps something other than message-sending
semantics would be better, since that's an awful lot to hide behind
the dot. Maybe a block-wise evaluation of some kind?

David

···

On Thu, 24 Aug 2006, Nathan Smith wrote:

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

On Thu, 24 Aug 2006, Nathan Smith wrote:

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

On Thu, 24 Aug 2006, Nathan Smith wrote:

On Thu, 24 Aug 2006, Douglas A. Seifert 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.

Matthew_Johnson · 23 August 2006 22:03

>> # Sigh -- Matz, *please* can we have this?
>> def singleton_class
>> class << self; self; end
>> end

+100 - please give us singleton_class!

I concur as well and have been using this myself.

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.

or the alternative:

def singleton_eval &b
singleton_class.module_eval &b
end

7rans · 25 August 2006 14:20

Justin Bailey 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:
> >
> >> # Sigh -- Matz, *please* can we have this?
> >> 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'.

T.

Ara.T.Howard6 · 25 August 2006 14:29

you could say exactly the same thing about Class.new, Module.new, etc. i
think the advatage is that

obj = Object.new

   obj.singleton_class.module_eval{ def foo() 42 end }
       ^^^^^^^^^^^^^^^ ^^^^^^^^^^^
       hard to explain. harder. where's the module?

block methods in ruby save time and code scanning.

2 cts.

-a

···

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

I'd rather not see module_eval wrapped/hidden in singleton_class. I
see singleton_class as a kind of twin method with class. In part I'm
hoping for this because I think it will make it vastly easier for
people to understand the basic premise that an object has a [birth]
class and a singleton class, from both of which it draws its
behaviors. I don't see an advantage to adding a special twist to
singleton_class. If it gives you a class object, you can always call
module_eval on that, as with any class object.

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

Nate_Smith2 · 24 August 2006 14:57

Hello,

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

   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

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"

> This isn't what is wanted when calling super.someMethod (that would
> be like doing super.class.someMethod, which is different). I
> recognize Ruby is different from other langauges, but many other
> languages (even less OO capable languages such as Java and C++) have
> the use of the "super.someMethod" functionality.

Well... it's probably good that Ruby isn't a superset of those less OO
capable languages

I'm not suggesting that Ruby be a superset of those languages (and I'm
glad it isn't) -- I'm suggesting that the other languages got the
terminology right in using both the "self" and the "super" keywords in the
same context.

But I'm getting confused by the use of an existing keyword to describe a
new concept. Also, it's not clear what the keyword would actually
produce. You're sending the someMethod message to it, but from what I
understand you don't really mean it to respond to that method, but
rather to re-send the message to the current self, using the constraint
that the currently visible version of the method be skipped.

I do want the message to be responded to. Calling super.someMethod would
pass the someMethod message to the super object. The message is not being
re-sent to any object, nor is it being routed through any object. It is
being sent directly to the super object.

"super" would either point to the superclass of self (the instance
version), or (in the case of self.class.super), would refer to the
metaclass of the superclass of self.

Perhaps Matz wants to keep the metaclass completely hidden from the
programmer (indeed, it is hinted so in Programming Ruby), and I can see
the merits in doing so. This still requires more work for the programmer
to be able to perform what was stated earlier in this thread.

Nate

···

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

Christian_Neukirche1 · 25 August 2006 09:51

Matthew Johnson <musical.matthew@mac.com> writes:

>> # Sigh -- Matz, *please* can we have this?
>> def singleton_class
>> class << self; self; end
>> end

+100 - please give us singleton_class!

I concur as well and have been using this myself.

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

···

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

Ara.T.Howard6 · 25 August 2006 14:41

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

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

-a

···

On Fri, 25 Aug 2006, Trans wrote:

Justin Bailey 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:

# Sigh -- Matz, *please* can we have this?
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'.

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

Rick_DeNatale1 · 26 August 2006 02:26

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). Now if I might dredge up some
Smalltalk terminology, I might suggest that we call:

The singleton class of an instance its 'behavior' and
The singleton class of a class its 'metaclass.'

Classes are about representing a 'class' of instances: instantiating
them and providing common behavior. Despite what folks like why have
written, metaclasses really should be considered something which is a
feature of classes and not any arbitrary object. That's why the word
is metaCLASS.

The term 'behavior' here, as is about simply having behavior (i.e. a
set of methods).

Of course all three of these things (behavior, class, and metaclass)
are also just links on the chain of objects which define all the
methods inherited by an object, or a class.

The more I think about this the more I like the terminology,

But that's just what I think.

···

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

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

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

--
Rick DeNatale

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

David_A_Black3 · 26 August 2006 10:01

Hi --

I'd rather not see module_eval wrapped/hidden in singleton_class. I
see singleton_class as a kind of twin method with class. In part I'm
hoping for this because I think it will make it vastly easier for
people to understand the basic premise that an object has a [birth]
class and a singleton class, from both of which it draws its
behaviors. I don't see an advantage to adding a special twist to
singleton_class. If it gives you a class object, you can always call
module_eval on that, as with any class object.

you could say exactly the same thing about Class.new, Module.new, etc.

Yes, but you *can't* say the same thing about #class, which is a more
level comparison with #singleton_class.

i think the advatage is that

obj = Object.new

obj.singleton_class.module_eval{ def foo() 42 end }
^^^^^^^^^^^^^^^ ^^^^^^^^^^^
hard to explain. harder. where's the module?

Well, I was just using module_eval to match your usage; I would
normally use class_eval for a class I'm afraid I don't see what's
hard to explain or use about it. You've got a method that returns a
Class object; you send a message to that Class object. It seems like
the most natural possible kind of sequence.

block methods in ruby save time and code scanning.

You're ascending to a kind of bird's-eye view, though. When it comes
to any given specific method, I'd rather examine the suitability of a
block in close-up. In this particular case, I dislike the prospect of
this equivalency:

obj.class.class_eval { ... } # class_eval one method away
obj.singleton_class { ... } # class_eval magically available

David

···

On Fri, 25 Aug 2006, ara.t.howard@noaa.gov wrote:

On Fri, 25 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.

ts1 · 24 August 2006 15:10

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

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"

Guy Decoux

Topic		Replies	Views
Calling super methods ruby-talk	15	89	6 October 2004
Q: How to call parent method explistly? ruby-talk	5	171	25 February 2011
Super super? ruby-talk	12	120	20 May 2009
Superclass method calling problem ruby-talk	2	78	10 October 2002
Parent class cannot call child class method ruby-talk	2	128	18 January 2008

Call functions of superclass

Cons

Related topics