[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
