[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-dev] language: declare advisedby
|
I'd like to see some kind of architectural spec, with enforcement as well.
My main point is just that any real solution to the problem has to
incorporate:
HOW the join points are identified, not just what join points
are identified. While set(int Point._x) and set(*.*) both match
sets of the private field Point._x, they are very different
from an SE/maintainability perspective.
WHAT the advice does. If you want to reason about the system as
a whole, what the advice does is key. For example, if I'm
concerned with real-time properties of a particular code segment,
I have a different perspective on advice within that segment
than at other times.
So I guess I'm saying that I'm skeptical that any scheme that just
matches join points will suffice. It has to be a scheme that talks
about properties of pointcuts themselves (PCDs) and advice bodies.
> -----Original Message-----
> From: aspectj-dev-admin@xxxxxxxxxxx
> [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Macneil Shonle
> Sent: Wednesday, December 24, 2003 2:27 PM
> To: aspectj-dev@xxxxxxxxxxx
> Subject: RE: [aspectj-dev] language: declare advisedby
>
>
> I think it would be nice to see more architectural-level
> descriptions in
> aspects, such as what Wes proposed. For example, a design
> spec might say
> that a program follows a layered architecture, but I might
> not believe it
> until I either observe every line carefully or have a tool that could
> verify it for me (for example, something similar to ArchJava).
>
> These kinds of aspects more valuable as a documentation tool
> over anything
> else. In Gregor's example I would imagine the architect of the whole
> program, rather than the implementor of the single class,
> would want to
> say what does and does not affect the class. In other words,
> the author of
> a class shouldn't/wouldn't know if an aspect should affect
> that class, but
> the person gluing it all together will.
>
> Though, instead of the declare error style proposed, maybe it could be
> more an implicit set that everything gets intersected with,
> providing for
> the exclusion (though this wouldn't cover the case of intertype
> declarations). Think of this implied universe of discourse
> set as a way to
> advice pointcuts (ie. to add the && myuniverse clause to existing
> pointcuts).
>
> -Macneil
>
> > Various versions of this idea have been presented in AOSD workshop
> > papers, or submissions to the main conference.
> >
> > *MY*OPINION*, as I said in my talk last year, is that this sort of
> > version of this kind of feature is a bad idea. The reason
> being that it
> > goes against the basic AOP hypothesis, which is that what
> you want to do
> > at a (dynamic or static) join point depends on the system
> as a whole,
> > and the implementor of the specific class in question can't
> really know
> > what should or shouldn't be allowed to happen there. That's
> the (better
> > way of saying) the obliviousness intuition.
> >
> > If this kind of feature gets into the language people will naturally
> > over-use it, and then things will be a mess.
> >
> > I believe that we will have a feature like this in the
> future, but it
> > will be based on a combination of talking about HOW the
> dynamic/static
> > join point is referenced, and WHAT the advice/introduction
> does. I think
> > that's hard to figure out, but for the first time two weeks
> ago I saw a
> > coherent talk by type guy (Martin Rinard) about what it
> would take to
> > figure out this kind of enforcement mechanism. So I'm
> hopeful we might
> > see a workable version of this feature in a couple of years.
> >
> >
> >
> > > -----Original Message-----
> > > From: aspectj-dev-admin@xxxxxxxxxxx
> > > [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Wes Isberg
> > > Sent: Tuesday, December 23, 2003 5:30 PM
> > > To: aspectj-dev@xxxxxxxxxxx
> > > Subject: [aspectj-dev] language: declare advisedby
> > >
> > >
> > > In some cases, I'd like to ensure that aspects do not
> > > affect a particular type or set of join points. It is
> > > not that an aspect must be disabled, but that some bunch
> > > of code must stay as-is. We might like to say
> > >
> > > - the non-public interface of this set of classes
> > > is off-limits
> > >
> > > - nothing should affect this aspect
> > >
> > > - we can't change the interfaces or fields of a set
> > > of classes deployed in the wild
> > >
> > >
> > > The syntax might be something like:
> > >
> > > declare unadvised: {pointcut} {: "message"};
> > > declare unaffected: {type-pattern} {: "message"};
> > >
> > > (where pointcut is staticly-determinable)?
> > >
> > > The semantics:
> > >
> > > declare unadvised: pc() : "message";
> > >
> > > specifies that if there is any advice on the join points picked
> > > out by pc(), the compiler will emit an error containing "message".
> > >
> > >
> > > declare unadvised: pc();
> > >
> > > specifies that no advice will be implemented on the join points
> > > picked out by pc(). No message is emitted. For developers who
> > > want a message in any case, we can support an XLint message
> > > (off by default) detecting that advice has been suppressed.
> > >
> > >
> > > declare unaffected: Type+ : "no members on Thread";
> > >
> > > specifies that no inter-type declarations are implemented on
> > > types identified by Type+. Like declare-unadvised, this emits
> > > an error if a messages is included, and is silent otherwise,
> > > unless the corresponding XLint message is enabled.
> > >
> > >
> > > Semantic variants and caveats:
> > >
> > > - declare-unaffected could also prohibit any join points
> > > implemented within Type+, but since it is easy to say
> > >
> > > declare unadvised : within(Type+)
> > >
> > > it seems better to maintain separate semantics.
> > >
> > > - If an aspect is declared to dominate the aspect containing
> > > the declare-unadvised/unaffected statement, then the compiler
> > > can permit the caveat by implementing the advise and inter-type
> > > declarations of that aspect.
> > >
> > > - To be more general, we could use friends:
> > >
> > > declared advisedby {typepattern} : {pointcut} {: "message"};
> > >
> > > e.g.,
> > >
> > > declared advisedby com.company.as..* : within(com.company..*);
> > >
> > > The "unadvised" case is just
> > >
> > > declared advisedby !Object+ : {pointcut} {: "message"};
> > >
> > > This permits us to have controlled aspect interactions,
> > > rather than just prohibiting them:
> > >
> > > declared advisedby (com.company.lib.sync..*)+ :
> > > synchronizationPoints();
> > >
> > > Implementation:
> > >
> > > The implementation for advice is to have a munger that aborts
> > > further munging. I'm not sure about the implementation
> > > for inter-type declarations.
> > >
> > > Drawbacks and alternatives:
> > >
> > > This scatters the definition of crosscutting by permitting other
> > > aspects to disable advice, possibly without warning. This effect
> > > is mitigated by notice from the XLint message, and could be
> > > supported in the IDE by listing advice disabled by a given
> > > declare-unadvised statement (and perhaps using syntax-highlighting
> > > to grey out disabled advice and declarations?).
> > >
> > > Benefits:
> > >
> > > This can implement some broad policies about the use of aspects.
> > > This can help people do incremental adoption, particularly to
> > > adopt binary aspects, and ensure that some code is untouched.
> > > It might also help in debugging aspects themselves.
> > >
> > > This provides some protection against the variability introduced
> > > by using AOP/AspectJ. More than just respecting Java's
> > > type-safety and visibility rules, AspectJ can do more to give
> > > developers a way to control aspect interference and interaction.
> > >
> > > Comments?
> > >
> > > Wes
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > aspectj-dev mailing list
> > > aspectj-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> > >
> >
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> >
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
