Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] New intertype syntax ...new meaning?
Personally I've never used a guard like that, although I guess I can see how it would be useful. It seems like what it boils down to is that both methods are useful but inlining is preferred by most users.
My first thought about the two syntaxes functioning differently is that it isn't intuitive enough to a new user. If anything I would expect the opposite, that field and methods that appear to be defined directly on a type, like: 

private Object Type.name
Would be inlined and that those contained in a block would be mangled/ encapsulated. Also, since guards do seem useful and they will probably continue to be used, shouldn't those using them also be able to benefit from writing ITDs with the new syntax, and shouldn't people who want to switch to the new syntax still be able to use them?
I think that using annotations is probably the way to go here, but I don't know if an annotation on each ITD member itself would be right. What if that was one option, but the annotation could also be applied to the aspect that contains an 'old style' ITD: 


@Inline
public aspect ITDAspect{

  public String ITDInterface.nonInlinedValue = "I'm not inlined";

}
To a 'new style' ITD or to the class that receives the ITDs members. The last case would be helpful to resolve conflicts because if you had: 

public aspect ITDAspect{

	@Inline
	intertype(ITDInterface){
	  ...
	}

}
and your application of that ITD to a particular class caused a conflict, the compiler could error out until you explicitly stated:
@Mangle(classes = ITDInterface.class) //Can't think of a better name off the top of my head 
public class Impl implements ITDInterface{

.......

}
and alternatively, if you are using an old ITD packaged in a 3rd party jar that you want to inline you can use: 

@Inline(classes = ITDAspect.class)
public class Impl implements ITDInterface{

.......

}
I had tried to accomplish something like this in my last post by placing the annotation on the implemented type.... which I of realized afterwards can't be done. This would serve the same purpose though.
I don't tend to define members for more than one type per aspect. Does anyone else? 

On Nov 24, 2009, at 2:14 PM, Andy Clement wrote:


I'm nervous about making changes to what happens for weaving todays
ITD syntax - meaning the ongoing discussions about mangling,
visibility, etc.  A common request I am now seeing is that users want
completely transparent application of ITDs.  What does what mean?  It
would mean in the bytecode it looked *exactly* as if the user had made
the ITD declaration in the target type.  I am thinking about whether
the new syntax block (intertype X {}) could implement this new
functionality and the user makes a deliberate decision about whether
they need the features that come with non-transparent ITDs, or if they
are happy with full inlining (and so choose the new syntax):

What goes wrong if fully inlined?  Here is a scenario:

class Foo
 public void m() {
   System.out.println("hey!");
 }
}

aspect Bar {
 public void Foo.run2() {
   System.out.println("hey2!");
 }
declare warning: execution(* run2(..)) && !within(Bar): "Only Bar
should be providing a run2 implementation";
}

This is (a crude representation of) a common pattern where an aspect
and bunch of ITDs implement some feature, but there is also a guard
"declare warning" in the aspect to make sure no-one attempts to
duplicate what the ITDs are already responsible for.  The above works
because post compilation the implementation of run2() is still
considered to be in Bar, with various accessors/dispatchers added to
Foo to support running the code in Bar.

If full inlining is performed, it would not be possible to tell that
Bar had provided the implementation of run2() into Foo - the bytecode
will look exactly like the code had been written:

class Foo {
 public void m() {
   System.out.println("hey!");
 }

 public void run2() {
   System.out.println("hey2!");
 }
}

I *think* there is a certain class of aspect that does fit this model
and doesn't need the distinction to be maintained in the bytecode
(remember, AspectJ is a bytecode weaver and does not really allow
source knowledge to influence weaving).  If you use ITDs, do you use
declare warning guards that would be impacted by fully inlined ITDs?

(Of course, even if this were happening, AspectJ will still be
informing the user of all the clashes that may be occurring due to
ITDs interfering or clashing with existing members)
Changing the meaning of existing syntax to do inlining could be made optional 

@Inline public void Foo.run2() {}

but I'm thinking that inlining may be default for the new syntax,
perhaps unless deliberately switched off.  or is that too confusing?

any thoughts?

Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top