T. Onoma
11/28/2003 1:45:00 AM
On Thursday 27 November 2003 07:46 pm, Peter wrote:
> I think I see the cause of the misunderstanding... Your use of method
> wrapping is meant to create a complete implementation of a method. Each
> wrapper adds extra functionality or changes the signature. A good example
> is a basic class that works on bare data, and wrappers are added to pack
> and unpack the data, which is really an orthogonal issue. But I would
> always have created either adapters for that, or just used helper methods,
> although wrapping sounds more convenient to me.
>
> My idea of AOP was a bit different. I wanted to know what AOP was about
> and so I attended one of the AspectJ guys' tutorials, and I guess I'm a
> bit biased because of their limited implementation. But the main point in
> their talk for using AOP was something like logging. When they add an
> aspect to a method, it doesn't change signature (a signature change in
> Java means method overloading I believe). Also you can add aspects to
> methods of other people's classes that don't add functionality, but just
> "hack in" for your own vile purposes. Things like logging or keeping
> statistics is a simple example of that (they overuse these examples). And
> they are on another level of orthogonality because they don't necessarily
> care about the number of arguments or the type of these arguments. Or they
> care about just part of that signature, and with some care that can be
> left unchanged by e.g., only adding new arguments at the end.
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.
> So my conclusion is that there are two kinds of wrappers: those that make
> up the base implementation (i.e., the primary method and its required
> wrappers) and wrappers added for "meta-tasks". The former ones need to be
> treated as a whole, but the latter ones do not - again, if taken care. I
> agree that the base implementation must go when the primary method is
> changed, but not those "meta-task" wrappers. And I do think that removing
> the latter automatically will create some hassle, but for the former I
> think that it's OK to do so.
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.
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).
-t0