From: "Hal E. Fulton" <hal9000@...>
Date: 2003-05-22T00:06:43+09:00
Subject: Re: super, aliases, defadvice, AOP, and so on

----- Original Message ----- 
From: <dblack@superlink.net>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Wednesday, May 21, 2003 9:35 AM
Subject: Re: super, aliases, defadvice, AOP, and so on


> I don't know about defadvice either, but a thought or two anyway:
> 
> 'prior' might have a usefulness, but it would not be a drop-in
> replacement for what alias currently does (which of course is also
> very different from what super does).  alias'ing a method makes that
> method callable in a general way, so:

[snip]

I'm not interested in a drop-in replacement for
alias, as such. I'm interested in a standard, 
simplified way to extend the functionality of
an existing method -- which we currently do by
aliasing the old method, redefining it, and
invoking the alias from within the new method.

Hmm, I'll bet something like this can be done
in Ruby as-is (thinking, thinking...).

> I have some instinct that tells me that a method cannot, as a general
> matter, "know" that it is replacing an existing method (because it may
> or may not be, depending on dynamically evaluated conditions), but I
> can't quite think my way through it.  Perhaps I'll try to babelfish
> thing with Matz's weblog :-)

Well, I'm in hesitant disagreement.

The interpreter certainly can "know" that a method
is being redefined; and in keeping with Ruby's 
reflective nature, I'd like to see that knowledge
available to the program. At least, I think I would!

And yes, we'd have to deal with situations where
the feature was used meaninglessly (both static
and dynamic); just as it's possible to use "super" 
in a context that makes it meaningless. (In many
cases, this will be caught at so-called "compile 
time"; but my gut tells me we could contrive a
scenario where it couldn't be determined until
runtime).

Hal