From fccbab59a264a7351822adcadd65af8570f216e8 Mon Sep 17 00:00:00 2001 From: aclement Date: Thu, 5 Mar 2009 23:38:45 +0000 Subject: [PATCH] declareMixin --- docs/adk15ProgGuideDB/ataspectj.xml | 194 ++++++++++++++++++++++++++-- 1 file changed, 185 insertions(+), 9 deletions(-) diff --git a/docs/adk15ProgGuideDB/ataspectj.xml b/docs/adk15ProgGuideDB/ataspectj.xml index 939a838c7..59d2e7996 100644 --- a/docs/adk15ProgGuideDB/ataspectj.xml +++ b/docs/adk15ProgGuideDB/ataspectj.xml @@ -648,17 +648,37 @@ Inter-type Declarations - Inter-type declarations are challenging to support using an annotation style. - It's very important to preserve the same semantics between the code style - and the annotation style. We also want to support compilation of a large set - of @AspectJ applications using a standard Java 5 compiler. For these reasons, - the 1.5.0 release of AspectJ 5 only supports inter-type declarations - backed by interfaces when using the annotation style - - which means it is not possible to - introduce constructors or fields, as it would not be not possible to call - those unless already woven and available on a binary form. + Inter-type declarations are challenging to support using an annotation style. For code style aspects, + compiled with the ajc compiler, the entire type system can be made aware of inter-type declarations (new + supertypes, new methods, new fields) and the completeness and correctness of it can be guaranteed. + + Achieving this with an annotation style is hard because the source code may simply be compiled with javac + where the type system cannot be influenced and what is compiled must be 'pure java'. + + + AspectJ 1.5.0 introduced @DeclareParents, an attempt to offer something like that which is achievable with + code style declare parents and the other intertype declarations (fields, methods, constructors). However, + it has proved too challenging to get close to the expressiveness and capabilities of code style in this area + and effectively @DeclareParents is offering a mixin strategy. The definition of mixin I am using here is that + some interface I is mixed into some target type T and that means all the methods from I are added to T and their + implementations are simple forwarding methods that call a delegate which that provides an implementation of I. + + + The next section here talks about @DeclareParents and what is possible, but moving forward, starting with + AspectJ 1.6.4, we are offering @DeclareMixin - an improved approach to defining a mixin and the choice of a different + name will hopefully alleviate some of the confusion about why @DeclareParents just doesn't offer the same + semantics as the code style variant. Offering @DeclareMixin also gives code style developers a new tool for a simple + mixin whereas previously they would have avoided @DeclareParents thinking what it could do was already achievable with + code style syntax. + + + In future releases the @DeclareParents support may be deprecated if it cannot be made more similar to code style. + + + @DeclareParents + Consider the following aspect: @@ -798,6 +818,162 @@ If the interface defines one or more operations, and these are not implemented by the target type, an error will be issued during weaving. + + + + + @DeclareMixin + + Consider the following aspect: + + + + + + This declares an interface Moody, and then makes two inter-type declarations on the interface + - a field that is private to the aspect, and a method that returns the mood. Within the body of the inter-type + declared method getMoody, the type of this is Moody + (the target type of the inter-type declaration). + + + Using the annotation style this aspect can be written: + + + + + + Basically, the @DeclareMixin annotation is attached to a factory method. The + factory method specifies the interface to mixin as its return type, and calling the method should + create an instance of a delegate that implements the interface. This is the interface which will + be delegated to from any target matching the specified type pattern. + + + + Exploiting this syntax requires the user to obey the rules of pure Java. So references to any + targeted type as if it were affected by the Mixin must be made through a cast, like this: + + + + + + Sometimes the delegate instance may want to perform differently depending upon the type/instance for + which it is behaving as a delegate. To support this it is possible for the factory method to specify a + parameter. If it does, then when the factory method is called the parameter will be the object instance for + which a delegate should be created: + + + + + It is also possible to make the factory method non-static - and in this case it can then exploit + the local state in the surrounding aspect instance, but this is only supported for singleton aspects: + + + + + Although the interface type is usually determined purely from the return type of the factory method, it can + be specified in the annotation if necessary. In this example the return type of the method extends multiple + other interfaces and only a couple of them (I and J) should be mixed into any matching targets: + + + + + There are clearly similarities between @DeclareMixin and @DeclareParents but + @DeclareMixin is not pretending to offer more than a simple mixin strategy. The flexibility in + being able to provide the factory method instead of requiring a no-arg constructor for the implementation also + enables delegate instances to make decisions based upon the type for which they are the delegate. + + + + Any annotations defined on the interface methods are also put upon the delegate forwarding methods created in the + matched target type. + + -- 2.39.5