Hi Alessio, yes, you can obviously branch your type hierarchy, but if you only need to test one implementation or the other, consider writing both the aspects and then including/excluding one or the other inside aop.xml .
Simone 2010/3/5 Alessio Pace <[email protected]> > Hi Simone! > > Thanks for you reply. As I wouldn't like to split my project in multiple > modules / jars, I see as only (?) solution the one of adding more > specification to the interface type hierarchy whose code will be provided by > my mixins who will implement that interface, in order to avoid conflicts. > > So basically: > > interface BaseBar { > void bar() > } > > abstract class BaseFoo implements BaseBar { > } > > Now I add also: > > interface BarFirst extends BaseBar { > void bar() > } > > interface BarSecond extends BaseBar { > void bar() > } > > abstract class FooSupposedToIncludeBarFirst extends BaseFoo implements > BarFirst { > } > > abstract class FooSupposedToIncludeBarSecond extends BaseFoo implements > BarSecond { > } > > aspect BarFirstImpl { > void FooSupposedToIncludeBarFirst.bar() { > // implementation of method > } > } > > aspect BarSecondImpl { > void FooSupposedToIncludeBarSecond.bar() { > // implementation of method > } > > I don't mind having to specify sub (abstract) classes + sub interfaces to > avoid conflicts. I was wondering if this approach is reasonable. > In fact, what I need to do is test different implementations of the > (BaseBar) mixin within the general behaviour of the class BaseFoo that will > "receive" its code and simply drive it. > > Thank you for any comment. > ciao, > Alessio > > > On Fri, Mar 5, 2010 at 12:08 AM, Simone Gianni <[email protected]> wrote: > >> Ciao Alessio, >> >> what you created are in fact two ITD methods, and since both of them >> implement the same method, the compiler will complain. >> >> Mixins in AspectJ are not dynamic, they are static type changes, cause >> Java is statically typed and AspectJ does not change this. >> >> For example, suppose you have an interface named Timestamped, that >> declares : >> >> public interface Timestamped { >> public void setTimestamp(); >> public long getTimestamp(); >> } >> >> As a contract, when the setTimestamp is called, the instance should record >> the current milliseconds, and return it when getTimestamp is called. >> >> As obvious, it is a tedious and error prone work to implement the same two >> methods in every class that needs to implement such interface, and to keep >> them up to date when specifications change, not to mention that probably >> there are many other similar interfaces, like Loggable with its setLogger >> and getLogger etc.. >> >> In Java one of these interfaces can be implemented in an abstract class, >> but since each class can only extend one other class, if you need both >> Timestamped and Loggable you'll end up having to implement one of the two. >> >> In AspectJ you can declare an aspect for this : >> >> public aspect TimestampedImpl { >> private long Timestamped.timestamp = 0; >> public void Timestamped.setTimestamp() { >> timestamp = System.currentTimeMillis(); >> } >> public long Timestamped.getTimestamp() { >> return timestamp; >> } >> } >> >> And do the same for Loggable in a LoggableImpl and so on for any other >> interface. >> >> Now, you can simply write : >> >> public class MyClass implements Timestamped, Loggable { } >> >> And see that MyClass "inherits" setTimestamp, getTimestamp etc... from the >> Timestamped interface, and setLogger and getLogger from Loggable, that is >> multiple inheritance. >> >> Also, you can override those methods by simply declaring them in the >> target class .. if for example you have a corner case where MyClass wants to >> return always 0 for getTimestamp : >> >> public class MyClass implements Timestamped, Loggable { >> public long getTimestamp() { return 0; } >> } >> >> The way it works is applying (copying verbatim) the bytecode of the method >> declared in TimestampedImpl inside classes implementing Timestamped, unless >> the method is already there. >> >> If you have more than one TimestampedImpl aspects in your classpath, there >> is no way to select one or the other at run time, cause the modification is >> at bytecode level so the type is statically determined. >> >> In that case, you can include only one or the other TimestampedImpl >> implementation using the aop.xml file, or placing them in two different .jar >> files and adding only one of them in the classpath at build/runtime >> (depending on the type of weaving you are using), or do the same with Maven >> creating two different artifacts and including them as dependencies in two >> different profiles .. anyway, once the application is built, only one of the >> two implementations will have been woven in. >> >> Hope this helps, >> Simone >> >> >> 2010/3/4 Alessio Pace <[email protected]> >> >>> Hi, >>> >>> I was trying to make some simple mixins using AspectJ. >>> >>> My scenario is the following. I have an (abstract) class, let's say Foo, >>> that implements the interface Bar, and that has a template method in which >>> it calls the methods provided by the Bar interface. >>> >>> interface Bar { >>> String barMethod(); >>> } >>> >>> abstract class Foo implements Bar { >>> >>> public void run() { >>> System.out.println( barMethod() ); >>> } >>> } >>> >>> so, I would like to have various mixins which can provide the Bar >>> implementation, and only choose one of them to be actually merged in. >>> >>> I was trying to adopt the approach of writing them in the following way: >>> >>> public privileged aspect BarAspect_First { >>> public String Foo.barMethod() { >>> return "First"; >>> } >>> } >>> >>> >>> public privileged aspect BarAspect_Second{ >>> public String Foo.barMethod() { >>> return "Second"; >>> } >>> } >>> >>> but clearly Eclipse/AJDT complains about conflict inter-type >>> declarations. >>> >>> So going back to my question, how do I declare the mixins and them be >>> able to specify which one to actually be used? >>> >>> Thanks in advance for any suggestion. >>> Regards, >>> Alessio Pace. >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >>> >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
