RE: [aspectj-dev] language: declare advisedby

["Gregor Kiczales" <gregor@xxxxxxxxx>]

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
>