David A. Black a écrit :
> Hi --
> 
> On Sun, 10 Apr 2005, Lionel Thiry wrote:
> 
>> David A. Black a crit :
>>
>>> I agree that the non-special case should be what it is now, and the
>>> case where you don't want overriding should be the one that requires
>>> something extra.  But I don't think it should be based on overloading
>>> "self" (and I believe having "self" refer to the class context, rather
>>> than the object, is a kind of overloading).  If this mechanism is
>>> really necessary, I would rather see:
>>>
>>>   class C
>>>     def process
>>>       # ...
>>>       C#util
>>>     end
>>>   end
>>>
>>> which is, I think, a more direct way of saying: protect this call from
>>> overriding in subclasses.  (Yes, everybody, I do know that this is
>>> comment syntax and would require a parser change :-)
>>>
>>>
>>> David
>>>
>>
>> class C
>>  def process
>>   # ...
>>   C::util
> 
> 
> That's different; that's a class method.

In present ruby, yes, C::util is identical to C.util.

But I was thinking of "C::util" as an explicit namespace specification, not as a 
message sending to C object.

You talked about adding some "#" new operator could be inadequate as it is 
usually used for comments. I was just indicating "::" could do the job.

Sorry for my lack of clarity.

> 
>>  end
>> end
>>
>> equivalent to
>>
>> class C
>>  def process
>>   # ...
>>   self.C::util
>>  end
>> end
>>
>> equivalent to
>>
>> class C
>>  def process
>>   # ...
>>   self.(C::util)
>>  end
>> end
> 
> 
> These last two don't really fit the dot semantics, and if they're
> alternatives to C::util, then they're dealing with a class method
> anyway (rather than the issue of limiting the effect of overriding
> instance methods).
> 
> My suggestion of C#util is based on the common use of # to mean
> "instance method of the named class or module".  It wouldn't require
> redefinition of the dot notation, nor overloading 'self' to be a
> boolean flag (as in the original proposal, where 'self' means both
> "the default object" and "don't redirect this to an overridden version
> of the method).

And what is your opinion, now, if you take for granted that "::" semantic is 
redefined?

--
Lionel Thiry