From: Robert Feldt <feldt@...>
Date: 2001-01-26T22:10:47+09:00
Subject: [ruby-talk:9927] Re: ANN: AspectR 0.2

Avi,

On Fri, 26 Jan 2001, Avi Bryant wrote:

> Having now actually looked over all of your modifications to my unassuming
> little hack ;-), I'm wondering if there might be a way of doing this that
> doesn't require quite so much textual manipulation of code... it's pushing
> the limit right now of what I'm comfortable with, although maybe that's
> just squeamishness on my part. 
> 
But I've always considered (self-)/(code-)modifying code an
underestimated development approach... :-)

I  wonder if its truly "dangerous" or if its only our experience with
traditional programming techniques and dogma.

> what about using method_missing as a dispatcher for wrapped methods?  That
> is, to wrap a method:
> -alias it, as we do now, to some mangled variation of its name
> -undef it
> -add the pre/post advice methods to a hash under the method name's key (in
> a hash local to the class, not a global one like you have now)
> 
We should probably go for a local hash anyhow.

> method_missing then checks if it's been given a wrapped method, and if so
> pulls the advice methods out of the hash, uses send() to make the calls,
> etc.
> It's a little bit of extra overhead (send instead of direct method call,
> and the extra call to method_missing) but it should make things a fair
> bit cleaner, nu?
> 
> Is there any reason this wouldn't work?
> 
Nope, it should. When I originally did my AOP stuff, performance was a 
concern so I didn't consider this an option but I guess the overhead
won't be too high in practice? Figures anyone? (I have to admit my main
source of inspiration for the AOP stuff was the discussion on the
'once' directive on pages 251-252 in pickaxe book, where performance is
the "goal")

My major concern is transparency. Using method_missing might not be
as transparent as the current approach. What if folks wanna wrap
method_missing? Or if they want to install their own method_missing? Or 
if they use other modules that wrap methods? Or if they call
public_instance_methods? We might be able to work around these issues but
we have to be careful. However, similar concerns arise even in
current design, or? Anyhow, IMHO transparency is top concern in AOP
module.

I guess we can parameterize on the dispatch strategy and let people
decide on their own? (I'd hoped for a way to apply AOP to AspectR itself
but I can't see how right now... ;-))

/Robert