[aspectc-user] aspect conflict resolution

[Olaf Spinczyk]

Hi Matthias,

mathias.kurth at s2000.tu-chemnitz.de wrote:
> Hello,
> 
> I've got a question about aspect conflict resolution in AspectC++. 
> I have the following aspects:
> 
> 	aspect Outer1 {
> 	  pointcut virtual p() = 0;
> 	  
> 	  advice p() : before() {
> 	    printf("before p in Outer1\n");
> 	  }
> 	};
> 
> 	aspect Outer2 : public Outer1 {
> 	  pointcut virtual p() = call("% %::Print(...)");
> 	
> 	  advice p() : before() {
> 	    printf("before p in Outer2\n");
> 	  }
> 	};
> 	
> How is the order of the advices to p() defined?
> In AspectJ it is said that all advices in the derived class
> do have prefenence over the advices in the base class.
> I've tried to apply this to the aspect compiler, but
> the result was the following:
> 
> 	static inline void a0_before_Outer2_call_main_FiiPPcE_0() {
> 		printf("before p in Outer2\n");
> 	}
> 	static inline void a0_before_Outer2_call_main_FiiPPcE_0() {
> 		printf("before p in Outer1\n");
> 	}
> 	static inline void __call_main_FiiPPcE_0_0 (::test::CAspectTest1 
> *dstthis) {
> 		a0_before_Outer2_call_main_FiiPPcE_0();
> 		a0_before_Outer2_call_main_FiiPPcE_0();
> 		dstthis->Print ();
> 	}
> 
> I think this is surely not the expected result. The generated
> output was not compileable with the backend compiler.

This is a code generation bug. I added it to bugzilla (bug 99). We will 
fix this problem as soon as possible.

> Another point is what would be if the pointcut was not virtual.
> How is the order defined if the base and the derived aspects
> do advice to some pointcuts which include the same join points?

There is no rule, which defines the order of advice execution, in 
AspectC++, yet. However, our goal is/was to adopt the AspectJ default 
ordering, but, for example, before advice of a base aspect is executed 
after before advice on the same join point in the derived aspect.

This behavior will change in the near future and a section on advice 
ordering will be added to the reference manual, which defines a default 
ordering rule that you can rely on.

> Is it possible or is something planned to trace all conflict situations 
> (means: the intersection of pointcuts is not empty) in a certain 
> project during a compiler run?
> I think this would be a very usefull feature.

No, but I like the idea as well. It's on the todo list now.

> Another question to the Aspect Ordering and Aspect Behavior Contracts
> mentioned in several documents (e.g. in the poster AspectC++ on 
> www.andreasgal.com, paragraph 3.3 and 3.2):
> It seems that these features are not implemented yet. So when
> will they be available?

The following kind of advice (ordering advice) was presented on the 
mentioned poster and during our demo at the AOSD'2003:

advice some_pointcut() : order (aspect_first, aspect_next);

This is a very flexible approach to define the advice order, as it can 
vary in different parts of the system and the order definition is not 
bound to the aspects 'aspect_first' or 'aspect_last'. It can be 
completely separated.

Although, there is a working implementation of this feature, we didn't 
distribute it with our free ac++ version, yet, because an even more 
flexible concept will be implemented soon:

advice some_pointcut() : order (first_pct(), next_pct());

first_pct() and next_pct() represent arbitrary pointcut expressions in 
this example, which describe the names of aspects. As the pointcut 
expressions might reference virtual named pointcuts, even abstract 
aspects get the power to define an aspect order. Another advantage (from 
the practical point of view) is that the aspect names don't have to be 
known (declared) where they are mentioned in your code.

> What happens, if you order the advices within a join point using
> a order-statement an you try to apply a second order (which is
> perhops different in terms of ordering)?
> Will you get an error or is the second one ignored or happens
> something other?

You will get a compile-time error, if there is conflicting ordering advice.

I know that there is no satifying solution to the ordering problem in 
the currently available implementation :-(. Please be patient, we will 
try to fix the default ordering and the code generation bug this week. 
Then it will be published with the next freely available version this 
week as well. For the ordering advice there will be an update in a few 
weeks.

Thank you very much for your helpful reports.

Yours,

Olaf