Re: [Meinds-developers] Aspect oriented framework, first go

[Rickard <ri...@xp...>]

Dmitri Colebatch wrote:

>>I have now finished the first working version of an Aspect Oriented 
>>Programming (AOP) framework. It is very simple, yet extremely powerful. 
>>I should be very useful as the base for the object model of Meinds.
>>
> 
> hehe... yes I agree... you are very useful for the object model for Meinds
> (o:  if only someone had thought to not make you a singleton!


LOL, I guess I deserved that one ;-)


> I _think_ I now see why state hasn't really been an issue... each aspect
> can simply control their own state - yeah?  


Yes, and the actual state management can be done by an interceptor, just 
like in EJB. In fact, an aspect can *be* an EJB hence using EntityBeans 
to perform the state management. That doesn't mean that the other 
aspects of a given object has to use EJB though.

> as the implementation of ACL
> does... so as far as persistence is concerned, that is where that would
> occur as well...  in UserImpl you have getName() simply returning the
> resource id - in reality UserBuilder will load an object from persistent
> store, and that is where the name would come from, yes?


Correct.


> one other little thing here, the term Builder, as I understand GoF use it,
> is a stateful throwaway object that you use to incrementially build
> something... aren't the Builders more like Factories?  or am I missing
> something?


Not really, since they may indeed be stateful. I used 
DocumentBuilder/DocumentBuilderFactory from JAXP as a comparison to what 
I wanted to achieve. The ObjectBuilders may indeed be stateful (that's 
why you register instances of them with the OBF), so I think it's an ok 
use of the term.

I'm not religious about it though :-)


> what is next on the list then?  


AFAICT the core framework that is there now is enough to get started. 
The horizontal compositioning (=adding features) is there, and the 
vertical compositioning (=adding behaviour) is there. All we need to do 
know is start using it, and see if the framework is somehow inherently 
flawed. If there's something I didn't think of, that needs to be fixed.

Also, there *is* a small performance hit for using this, since dynamic 
proxies are involved. I have minimized this by letting interceptors call 
other interceptors directly (instead of going through method.invoke), 
but there's always a hit of 0.03ms/call. It might be irrelevant in the 
big picture, but may become important when thousands of objects are 
being called during a process.

For the really performance-minded it *is* possible to extract objects 
from the compositioning and call them directly, but this should be done 
as little as possible since it makes the code harder to write/read.

> I'd be very keen in doing something here,
> and feel like I understand what you're doing in the code... I suppose a
> good start would be doco - do you have any thoughts on what structure the
> documentation should take (in terms of a toc)... I figure if I started
> there I would (a) ensure that I'm not completely missing something - or at
> least have it corrected by you, and (b) get the necessary evil of doco
> started at an early point...  thoughts?

Good idea. Steal the doco outline from WebWork (i.e. DocBook), since 
it's got the basic outline done, and also with a nice CSS stylesheet to 
go with it. The doco generation works well there too, which can be 
tricky to set up.

All set, soldier? Then move out :-)

/Rickard

-- 
Rickard Öberg