Summary: | within and pointcuts matching introduced method declarations on interfaces | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Vincenz Braun <vb> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | aclement, rbodkin+LISTS |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | Macintosh | ||
OS: | Mac OS X - Carbon (unsup.) | ||
Whiteboard: |
Description
Vincenz Braun
2007-07-28 20:35:14 EDT
Changing OS from Mac OS to Mac OS X as per bug 185991 This behavior is correct as I understand it. Within deals with lexical structure, not typing. You can use this(Marker) to match methods defined on Marker. It is a little surprising that this is withincode(String Marker.mark()) but I think it's useful to have the current AspectJ semantics. Per http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html "The within pointcut picks out each join point where the code executing is defined in the declaration of one of the types in TypePattern." Clearly mark is defined lexically within MarkerAspect and NOT within a subtype of Marker. For the given test case I see no problem at all in using this(Marker). But unfortunately the provided test case is too much condensed. Actually we wanted to use the pertypewithin instantiation model for an apsect. This aspect should then transparently be applied to Marker's regardless whether the interface and implementation of Marker were introduced or not. In this scenario we now loose this transparency. Writing aspect libraries we now have to consider the pertypewithin instantiation model more carefully. In some cases this means we can not use it at all and have to use our own per type management. I considered within from the byte code perspective. And I was surprised that although there is a mark() definition in Foo it is not matched. clarify for 1.5.4 within() is working as designed (lexical scoping) pertypewithin() is based on that, so working as designed. I basically understand Vincenz' point. Whether the member is introduced via an ITD can make a difference as to whether a pertypewithin related aspect would catch the execution of a method. I'm not sure how to proceed with the bug - it seems like there could be an enhancement in this area but I'd need multiple compelling use cases to justify any work done. |