Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] New intertype syntax ...new meaning?

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


Back to the top