From: Matt Hurd (matt_at_[hidden])
Date: 2004-04-02 05:39:34
David B. Held wrote:
> "Hurd, Matthew" <hurdm_at_[hidden]> wrote in message
> news:BA1220310B07EC4A8E321B451E07AF47314478_at_msgbal501.ds.susq.com...
>
>> [...]
>> "Aspect" might be inappropriate as I'm not 100% on my AOP
>> nomenclature, but it feels appropriate.
>> [...]
>
>
> I don't think "aspect" as you're using it here has anything to do
> with AOP. From what I can tell, AOP is something like "function
> prologue/epilogue code injection". That is, given a function, you
> can modify it with an aspect that causes certain code to run
> before or after it (sorta). I think of it as "RAII on 'roids". Anyway,
> it seems to me that AOP is all about functions, while the current
> thread is about GP, so I think this is a very confusing use of the
> term "aspect".
I'm not an expert in anything, but in my mind the aspect side of AOP is
a about being able to separate out different "aspects" of a design in a
similar way to what you can achieve with C++ policies. Usually they are
orthogonal but they don't have to be. And that's about it really. The
epilogue/ prologue stuff and the weaving comes down to specific
implementations. Aspect J is most comment probably, but it is not the
only way.
As I think about it, the epilogue prologue approach is just one way of
wrapping stuff, but the most obvious way if the concept has not been
design for an aspect. You can hardly shove a bunch of intrusive logic
in the middle of an arbitrary loop in a method, or can you? Generic
parameters are another way of introducing aspects, but the difference is
that the class has to be designed for it which is not a flexible. You
could chain together C++ types with an epilogue and prologue static
methods, or some such, that could provide a similar mechanism but the
weaving would be manual to the methods (could be automatic to the class
via the raii style) unless you used some trickery overloading ->, clever
proxying or some such like Stroustrup has with his locking paper from
memory. Maybe you could call such an aspect an aspect aspect ;-)
A lot of what policies is about (but not everything) is really giving a
lot of the same capability to C++. Aspect still seems like a good name
to me.
It would be good to have some standard naming conventions /
classifications in boost or as documented boost speak at least...
Regards,
matt.