On Mon, Oct 8, 2012 at 7:40 PM, Andy Clement <andrew.clem...@gmail.com>wrote:
> I would love to do something along these lines to smooth out this very > common use case. I'd also like to revisit the mangled accessors too > (and all the generated code). [snip] > It seems like the syntax could be a simple extension to whatever JDK 8 finalizes on for default methods (which are akin to stateless traits). Maybe keep this feature as a preview until after JDK 8 ships, so as to use their default method syntax... > But, as Alexander points out, on the list of priorities things that > have a workaround are lower than things which are broken right now. > > Agreed on priority. Perhaps we can find a student who'd like to do this for a project...how do you normally go about finding one? If I had the time, I'd love to do it, but, alas, clients call... > cheers, > Andy > > On 5 October 2012 09:06, Alexander Kriegisch <alexan...@kriegisch.name> > wrote: > > Cool idea. I would be guessing this might not be the highest priority in > > AspectJ development, considering other parts of AspectJ and especially > AJDT > > that need attention, but still if you ask "WDYT": cool. ;-) > > -- > > Alexander Kriegisch > > > > > > Am 05.10.2012 um 16:56 schrieb Matthew Adams <matt...@matthewadams.me>: > > > > I've used a common ITD pattern for years now to introduce interface > > implementation(s) into existing classes when I have well-encapsulated, > > orthogonal state & behavior that I want to introduce. Here's a simple > > example (hand-written, but gives you the gist): suppose several of my > > domain entities need to have a string property "name". > > > > First, define an interface that describes the behavior: > > > > package org.example.traits; > > > > public interface Nameable { > > String getName(); > > void setName(String name); > > } > > > > Next, define an annotation that can be used to drive introduction: > > > > package org.example.traits; > > > > @Target(TYPE) > > @Retention(RUNTIME) > > public @interface Expresses { > > Class[] value(); > > } > > > > Next, define an aspect that provides an implementation of the behavior: > > > > package org.example.traits; > > > > public privileged aspect NameableAspect { > > > > public interface I extends Nameable { > > } > > > > declare parents : (@Expresses(..,Nameable.class,..) *) implements I; > > > > private String I.name; > > > > public void I.setName(String name) { > > this.name = name; > > } > > > > public String I.getName() { > > return name; > > } > > } > > > > Last, annotate a class that needs to receive the ITD: > > > > package org.example.domain; > > > > // imports... > > > > @Expresses(Nameable.class) > > public class Person { > > } > > > > After considering JDK8's default methods feature and comparing it to > Scala's > > traits and mixins, I realized that AspectJ, with a little syntax sugar, > > could have the same features as Scala. The above example could be > rewritten > > as the following, depending on how many new keywords were introduced. > > > > First, define the trait's state & full or partial behavior using a > proposed > > new keyword "trait": > > > > package org.example.traits; > > > > trait Nameable { > > > > String name; > > > > void setName(String name) { > > this.name = name; > > } > > > > String getName() { > > return name; > > } > > } > > > > Here is what ajc would do with the trait: > > > > produce a public interface with the same name as the trait with the > trait's > > methods, and > > define an aspect that > > > > introduces the trait's fields and the implementations of the trait's > methods > > into the produced interface, and > > uses @Expresses to drive a declare parents statement to mix in the > > implementation into classes that are annotated with @Expresses. > > > > With this syntax, a user could simply declare that a class needs to > express > > the trait: > > > > package org.example.domain; > > > > import org.example.traits.Nameable; // interface generated from trait > > > > @Expresses(Nameable.class) > > public class Person { > > > > public Person(String name) { > > setName(name); > > } > > > > // ... > > } > > > > In summary, this proposal is just syntax sugar over features that are > > already present in AspectJ for quite a while. It would be nice, as part > of > > this enhancement, if > https://bugs.eclipse.org/bugs/show_bug.cgi?id=288282 > > could be resolved so that the ajc-generated, mangled accessors & mutators > > aren't present in the mixed in class (because > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=73507 is now fixed). > > > > WDYT? > > > > > > _______________________________________________ > > aspectj-users mailing list > > aspectj-users@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > -- mailto:matt...@matthewadams.me <matt...@matthewadams.me> skype:matthewadams12 googletalk:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users