Hi Didier,
one more question that came to my mind after scanning through the source
again: Do you REALLY need the programmatically realized concept of an
Aspect? Seems as if you could quite easily get along without it. Maybe I am
totally wrong. It was a rather casual look, trying to identify the places
where you actually use the Aspect interface.
Another thought: Maybe an Aspect is nothing more than an aggregation of some
other entities? Maybe the combination of Pointcuts plus Advices? Probably
not, but maybe that's a starting point?
Or maybe an Aspect belongs rather to the meta model of any given application
and as such is more of a descriptive term than an actual functional
programmatic entity? As such, it could be *mapped* to a combination of
Pointcuts and Advices.
Anyways, it's getting late ... Do not want to confuse you any more. As you
will notice, these are VERY preliminary thoughts on what seems to be a
rather tough question.
Cheers,
Olaf
>
> Olaf Bergner wrote:
>
> >Hi Didier,
> >
> >thanks. That worked. Had only a casual look, yet it appears very
> promising.
> >One note, though: you made the interface Aspect extend Startable and
> >Serviceable. While being no expert in Avalon concepts I still think that
> >this restricts your flexibility when it comes to implementing that
> >interface. I made it a habit of not letting the work interfaces of my
> >components extend any lifecycle interfaces. Work interfaces and lifecycle
> >interfaces describe two very different ... well, may I say,
> aspects (?) of
> >any given component. Work interfaces provide the client's view on the
> >component whereas the latter describe the container's view. The client is
> >and should not be concerned with the pecularities of the
> component it uses.
> >
> Well, i can only agree with you! In fact, this has took me the most of
> my design time. This may be seem ridiculous due to the size of the
> interface. However, here is my thought about this.
>
> I first started with a custom interface. I had to install and disinstall
> the aspect on demand. In order for the aspect to get the specific
> pointcut manager implementation, i had to give it to the aspect.
> So i made this:
>
> interface Aspect
> {
> public void install(PointcutManager pointcutManager);
> public void disinstall();
> }
>
> However, the core PointcutManager was not the only one an aspect may
> need. Althougth, it could get those other services via a standard
> service lookup.
> So i wondered why PointcutManager was priviledged compared to the
> others. (all the more since many people will only use the
> DesignatorPointcutManager once it will be implemented)
> From this, i decided that an aspect should retrieve all the pointcut
> managers via service lookups. So the aspect had only to be instalable
> and disinstalable. This pushed me to the Startable interface.
>
> Why i did decide to explicitelly put them in the Aspect interface is
> because i did not want a marker interface as i find this does not add
> value. Maybe there should not be any Aspect interface at all ? But then
> the AspectManager would not know what it starts and stops...
>
> Maybe i should came back to the first design above. Can you tell me what
> is your feeling with this ?
> Else what could be the benefit of a marker interface ?
>
> >Well, that's just my 2 ct. Anyways, hope to see this baby growing.
> >
> >Cheers,
> >Olaf
> >
> >
> That's not 2 ct for me that's lot more than 20 euros. :) Thanks very
> much for the comments.
> Hope *the baby* will be usefull for many ;)
>
> A+. Didier.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
