From: Sean O'Dell <sean@...>
Date: 2002-04-13T02:38:10+09:00
Subject: Re: Idea for a new shorthand

"Hal E. Fulton" <hal9000@hypermetrics.com> wrote in message
news:000b01c1e1f0$03d9f1a0$0300a8c0@austin.rr.com...
> OK, maybe this is an idea no one will like. Or
> maybe it's been thought of, maybe even
> rejected already. Maybe there's a reason it
> won't work. At 2 a.m. my time, it's not obvious.  :)
>
> Let me start by asking a rhetorical question:
> Why do we have the special name "super"?
>
> Obviously we could do it other ways. I'm just
> winging it here:
>
>     class Child < Parent
>
>       def mymeth
>           #...
>           Parent.mymeth
>       end
>
>     end
>
> But it's somehow cooler, neater, more logical to
> say "super" (is it not?).
>
> Now, consider this common situation.
>
>     alias old_system_method system_method
>
>     def system_method
>         if today == Sunday
>            # Do some other stuff...
>         end
>         old_system_method
>     end
>
> Do you see where I'm going? I propose a special
> name "prior" that will automatically refer to the
> prior definition of any method that is being replaced.
> No aliases will be necessary.
>
>     def system_method
>       if today == Sunday
>         # Do some stuff...
>       end
>       prior
>     end
>
> What do you think?

I may be off-base with this, but a problem jumped right into my mind doing
something like this.  How would mixins and class derivations appearing
before your class derivation affect the use of "prior?"  I am thinking that,
because class derivations can change a class somewhere hidden in a
"require", that you couldn't rely on what a call to "prior" would be
calling.  Probably 98% of the time it would be okay, but every so often you
would add a "require" to your code and then your class breaks because a base
method you were depending on is now replaced and you have no way to address
the one you wanted to call specifically.

    Sean