From: Avi Bryant Date: 2001-01-27T02:51:57+09:00 Subject: [ruby-talk:9943] Re: ANN: AspectR 0.2 On Fri, 26 Jan 2001, Robert Feldt wrote: > 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 seem to remember finding something like - normal method invocation - 1 send (using symbol) - 1.3 Method#call - 1.5 send (using string) - 1.8 My main concern is whatever overhead method_missing itself incurs... but, actually, method_missing is probably not the ideal dispatcher, since undeffing might do bad things to subclasses, along with the other trasperency concerns you had. Which means we have to at least re-def the wrapped methods to call our dispatcher, at which point I suppose we might as well just re-def those methods to *be* the dispatcher, for performance reasons, essentially as we do now. The thought that came out of all of this, though, was: perhaps we want to resolve our namespace issues by taking a metaobject* approach instead, and having the pre/post calls be to instances of an Aspect subclass (since we need a method hash now anyway - my original hack was trying to avoid that), rather than to methods in an included module. It enforces a little more encapsulation, which may or may not be a bad thing... should aspects have access to the private members of the object they're wrapping? Apologies for thinking out loud... avi *warning: I may be completely abusing terminology here...