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
