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
