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

-- 
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
http://www.manning.com/black     => book, Ruby for Rails
http://www.rubycentral.org       => Ruby Central, Inc.