[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

method search rule in 2.0?

David Garamond

4/9/2005 9:35:00 AM

I read:


http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Ruby2.0MethodSearchR...

and was feeling disturbed about this new Ruby2 behaviour.

class C
def process
# ...
util
end

def util
# ...
end
end

class CC < C
def util
# ...
end
end

CC.new.process # C#process expects C#util,
# but calls CC#util

Why is this a problem? Isn't it what people expect in OO? I'm not an OO
expert, but isn't this one of the supposedly unique feature/benefit of
OO: allowing old code to call new code. I believe it's called polymorphism?

Now Ruby2 wants to change so that 'util' in C method calls C#util and
'self.util' calls CC#util. I very much prefer 'self.util' to be the one
that calls C#util (and I don't think I'll ever use it a lot). The latter
is backwards compatible and how virtually all other languages behave.

Regards,
dave
21 Answers

Peter C. Verhage

4/9/2005 10:14:00 AM

0

David Garamond wrote:
> Now Ruby2 wants to change so that 'util' in C method calls C#util and
> 'self.util' calls CC#util. I very much prefer 'self.util' to be the one
> that calls C#util (and I don't think I'll ever use it a lot). The latter
> is backwards compatible and how virtually all other languages behave.

I totally agree with you.

I think a better way of solving this problem is using private methods
which are only part of the class for which they are defined. If a
subclass defines a method (private, protected or public) with the same
name as the private method in the superclass then all calls to the
private method made by methods in the superclass call the private method
in the super class. All methods calls on the method in the subclass call
the method defined there. Public or protected methods defined in
superclasses can be overriden in subclasses and when they are called
from the superclass the overriden method will be called. I believe this
is the way Java and C++ (among others) work.

Regards,

Peter

dblack

4/9/2005 11:26:00 AM

0

Csaba Henk

4/9/2005 12:05:00 PM

0

On 2005-04-09, David A. Black <dblack@wobblini.net> wrote:
> 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 :-)

As by the ruby of today, how you can do the above is:

class C
def process
# ...
C.instance_method(:util).bind(self).call
end
end

Now you will agree that it is not particularly convenient; but this is
how to do it... But. It's sooo long that you can't help remembering the
occasion if you use it.

And I don't remember doing it more that one or two times. That is, my
experience suggests that it's not a particularly frequent pattern. Which
means I agree with those who like the present state of the art.

Csaba

Lionel Thiry

4/9/2005 3:23:00 PM

0

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

equivalent to

class C
def process
# ...
self.C::util
end
end

equivalent to

class C
def process
# ...
self.(C::util)
end
end

--
Lionel Thiry

Trans

4/9/2005 4:13:00 PM

0

Ah, this is interesting. In the AOP work I've been doing, something
along these lines is a absolute must inorder to prevent method name
clashes and thus have fully reusable Aspects. My solution was to have
another scoping mechinism akin to public, private, protected, called
"local". It differs in that methods defined in the local scope are
always called locally in the context of that module, but not in the
context of any other. For instance:

class C
def x ; 1 ; end
end

class D
def y ; x ; end
local
def x ; 2 ; end
end

d = D.new
d.y #=> 2
d.x #=> 1

T.

dblack

4/9/2005 4:26:00 PM

0

Lionel Thiry

4/9/2005 8:36:00 PM

0

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

Paul Hanchett

4/9/2005 8:37:00 PM

0

David A. Black wrote:
> Hi --
>
> On Sat, 9 Apr 2005, David Garamond wrote:
>
>> I read:
>>
>>
>> http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Ruby2.0MethodSearchR...
>>
>>
>> and was feeling disturbed about this new Ruby2 behaviour.
>>
>> class C
>> def process
>> # ...
>> util
>> end
>>
>> def util
>> # ...
>> end
>> end
>>
>> class CC < C
>> def util
>> # ...
>> end
>> end
>>
>> CC.new.process # C#process expects C#util,
>> # but calls CC#util
>>
>> Why is this a problem? Isn't it what people expect in OO? I'm not an
>> OO expert, but isn't this one of the supposedly unique feature/benefit
>> of OO: allowing old code to call new code. I believe it's called
>> polymorphism?
>>
>> Now Ruby2 wants to change so that 'util' in C method calls C#util and
>> 'self.util' calls CC#util. I very much prefer 'self.util' to be the
>> one that calls C#util (and I don't think I'll ever use it a lot). The
>> latter is backwards compatible and how virtually all other languages
>> behave.
>
>
> 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 :-)

If I was writing class C, I would be surprised when CC#util got called,
but that is exactly the OO behavior you want sometimes. I think both
the naked call to util and self.util should be relative to the
/instantiated/ object.

If I really want to call C#util, why not say C::util? It seems like
anything else has compatibility problems...

Paul

dblack

4/9/2005 8:49:00 PM

0

dblack

4/9/2005 9:14:00 PM

0