From: "David A. Black" <dblack@...>
Date: 2005-04-10T11:35:52+09:00
Subject: Re: method search rule in 2.0?

Hi --

On Sun, 10 Apr 2005, Paul Hanchett wrote:

> David A. Black wrote:
>
>>> If I really want to call C#util, why not say C::util?  It seems like 
>>> anything else has compatibility problems...
>> 
>> 
>> C::util is a class method call,
>
> But if C#util is not defined as a with "def C.util ..." isn't it just a 
> regular method?  Or is C::util really a different sort of call to the class 
> object?

C#util is actually the constant C plus a comment :-)  This is all
speculative; there's no C#util expression in reality.

>> but what we're talking about here
>> pertains to instance methods.  The idea of C#util is not to call
>> C::util, but to call util on the instatiated object -- constraining
>> that call so that it is the #util defined in class C, not class CC.
>> 
>>   class C
>>     def x
>>       puts "I'm the #x from C"
>>     end
>> 
>>     def y
>>       x    # call the most recently defined #x at the time of the call
>>     end
>> 
>>     def z
>>       C#x  # call the x defined in C, no matter what
>>     end
>>   end
>> 
>>   class CC < C
>>     def x
>>       puts "I'm the #x from CC"
>>     end
>>   end
>> 
>>   CC.new.y    # I'm the #x from CC
>>   CC.new.z    # I'm the #x from C
>> 
>> Note that having a CC object "call the x defined in C" is different
>> from saying "Call the class method C.x" (which doesn't exist at all).
>
> Allowing an inheriting class to call an ancestor method without inheriting it 
> (i.e., skipping the inheritance chain) is not a good idea, I think.

I don't think that's what happening here (?).

> Of 
> course with Ruby you can retroactively redefine existing methods on 
> instantiated objects, right?  (I'm a Ruby NOOB, so I may have that wrong!)

Yes.  Well, it's not really retroactive -- the old method calls don't
get re-performed :-)  It's perhaps better described as happening
dynamically.  But, essentially, yes.

> An underlying assumption about OOD is that ancestor classes don't need to 
> worry about descendent classes changing the meaning of methods defined by the 
> ancestors.
>
> I think we will have to pick our poison-- Either there has to be a 
> declaration /in the class defintion/ whether a particular method is virtual 
> of not (C++), or we choose an object model where all methods are virtual 
> (Java and Python) or not (VB, I think).

I don't think the area that was addressed originally by the "self"
redefinition idea was that broad, design-wise -- that is, the basic
object model isn't under review, but just something very specific.
It's the following scenario: your superclass, inside an instance
method, calls another of its instance methods, expecting a particular
behavior, but that behavior has been changed by a subclass.


David A. Black
dblack@wobblini.net

-- 
David A. Black
dblack@wobblini.net