From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-28T11:46:33+09:00
Subject: Re: Method wrapping

> I see. Yes, that was one of the things I was trying to convey. I've read a bit
> about AspectJ. And certainly I am no AOP guru or anything, but after learning
> about it I quickly realized that it could do more than most people seemed to
> think it could. That's how I was able to design a GUI interface for a program
> without touching the original code. It just wrapped things, and thus was able
> to "plug-in", but the original code still ran just fine.

When I was listening to their tutorial, my feeling was that they kept
giving the same examples of logging and alikes, but that it was capable of
much more - though I couldn't find a good example. A GUI is indeed a
perfect example :-) But I guess I've been brainwashed by those OOP courses
telling me to use things like publish-subscribe, model-view-controller and
so on for that.

> I see what your saying. If you have wraps that are just monitoring/logging or
> what have you, then you might want to just change the primary function and
> still keep all the same "meta-tasks". I can see that point of view. So
> controlling the stack isn't really the issue, you just need to be able to do
> the "table cloth trick", so to speak. For this I would suggest just a
> different method, say, defroot, or something like that.

OK, but if those "meta-tasks" are combined with a primary method and its
own required wrappers, the defroot should change the primary method + its
wrappers.

> The question really boils down to which behavior should be the default. I
> think treating them as a whole is safer and generally more useful, so would
> be the better default. But mind you, I also think def itself should do
> wrapping without special syntax (as you may have seen from my AOP wiki page).

My proposition would have been to let wrappers be "sticky" by default
(sticking to the table cloth :-) and have an override to make a wrapper
"floating". If someone makes a "floating" wrapper, he should take care
when designing that wrapper. But since AOP is still in its baby stage -
and I don't know of an application in a dynamic language like Ruby - I
think only time can tell what's the way to go. If 2.0 gets it wrong, 3.0
will get it right :-)

As for def doing wrapping all by itself; I think I like the wrapper
methods better (sorry) because the inconsistency can easily be solved IMO.
Suppose you have class A, a subclass B, and a method foo. Each primary
method foo or wrapper foo:wrap/pre/post is part of a chain as long as they
call super. So the order in the chain is A#foo, all wrappers
foo:wrap/pre/post in A, B#foo, and all wrappers in B (that's what I'd
expect at least). I don't see why B#foo can't be left out from that chain.
A#foo gives a problem, but if B#foo would call super and A didn't have a
foo method, you have the same problem. It's consistent in the existant
problems :-)

Peter