From: Michael Neumann <mneumann@...>
Date: 2003-11-23T00:34:19+09:00
Subject: Re: Method wrapper question (was "stereotyping (was ...))

On Sun, Nov 23, 2003 at 12:10:35AM +0900, Gavin Sinclair wrote:
> On Sunday, November 23, 2003, 1:56:57 AM, ts wrote:
> 
> >>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:
> 
> G>> What difference does it make?  Import a method or define it yourself -
> G>> what's the big deal?
> 
> >  OK, but I want to do the same with normal methods
> 
> >> [...]
> 
> >  You have the same problem actually with methods, perhaps you just don't
> >  see it
> 
> 
> You're right, I don't see it.  A wrapper around a method is not a
> method.
> 
> I suppose it is possible that you could implement Ruby so that this
> behaviour ensues:
> 
>   class Example
>     def a; print "X"; end
>     def a; print "Y"; end
>   end
> 
>   Example.new.a              # -> "XY"
> 
> You'd have some potential issues with argument lists and return types,
> but if people wanted this behaviour, it would be technically possible
> to give it to them.  People wouldn't want it, though.

A big win would be a "prior" or "last_method" statement, similar to
"super", but which calls the first "a" in the upper example (instead of
the "a" of the superclass).

But that would mean that a class has to store multiple methods for each
method name, which might come out as a performance or memory problem. 

> It is equally technically possible to allow multiple method wrappers.
> The cultural resistence is, I predict, less, as we wrap methods all
> the time with ugly aliasing tricks, and there's no preventing
> multi-wrapping there.

It's easier to break automatic wrapping by undefining a method, than it
is to allow safe wrapping. But for normal methods, it's nonsense.

  class Example
    def a:pre; ...  end

    undef_method a:pre    # breaks multi-wrapping

    def a:pre; ...  end
  end

Anyway, I'd prefer the "prior" or "last_method" way.


Regards,

  Michael