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.