Re: [aspectj-users] How to remove "abstract" with AspectJ?

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hey,

> I'm sure there are other purposes of "abstract". But in my case, I
> consciously explicitly want my abstract class to de-abstract-ize itself.
> i.e. I'm simply using it to avoid typecasts while using @AspectJ
> annotations. And I'm still happy even if this de-abstract-izing will only be
> supported in build-time weaving.
>
> Yes I'm using it with annotation style (there's no problem with code style
> here).
>
> Shouldn't this be something that AspectJ supports?

How would AspectJ know which meaning you had attached to 'abstract'?
(whether it had your meaning, or it had mine which is to prevent
people creating instances of the type)  If I don't know the users
intent with specifying abstract in the source, I don't know if it is
safe to 'promote' to being non-abstract simply if you have supplied
implementations of all the abstract methods within it.  I would almost
need another kind of declaration to specify your intent: 'declare
deabstractify_if_complete_implementation: MyType'.

As I say, I wouldn't do this for annotation style.  For annotation
style you must be able to compile the code with javac - that is why we
have that style.  If you started treating types as if they were
non-abstract because you knew that is what the weaving process would
do, you'd be left with source that wouldn't build with javac.  yes, it
necessitates the ugly casts, but we can't control the type checking
that javac does.

For code style, I would consider making the change, but I need a least
a solution to that problem of knowing what the users intent for
abstract was.  There may be other problems too, as I say, I've not put
a lot of thought into it so far.  It is worth raising an enhancement
request to discuss it, but I'm not sure it will get implemented in the
short term without more discussion of the pros/cons and use cases. In
simple playing this morning, I observe in this case:

abstract class A implements I {
  abstract void foo();
}

aspect X {
  public void I.foo() {
    System.out.println("aaa");
  }
}

interface I { void foo();}

there appears to be something wierd going on as A doesn't get the ITD
implementation.  I would normally say, that's OK, but if I define:

class B extends A {}

and compile the whole lot I get no foo in B and the method is still
abstract - which makes it look like a bug that A didn't get foo's
impl.  I'd at least expect a real foo in A or B there...


cheers,
Andy