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

[Hendy Irawan <hendy@xxxxxxxxxxx>]

Andy Clement wrote:
> 
> 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
> 

Thank you Andy.

I realized my mistake there.

I was thinking something a long the lines of:

@DeclareNonAbstract(<type pattern>)

that can be attached to the aspect class itself.

But then realized it still won't possible to "new A()" since from the view
of Javac it's still abstract.

Probably a different way to do it is explicitly specify implementation
methods as "weak" or dummy.

e.g.

class A implements X {
  @Weak public String foo() { return ""; }
}

@Aspect class FooAspect {
  @DeclareMixin("A") X fooMixin() { new FooImpl(); }
}

Normal AspectJ rules are that the "host" methods take precedence. By marking
methods as weak, I allow the aspects to implement these methodss, and I
don't have to mark my classes as abstract.

Though now I'm not sure if I want to pursue any of these, Andy. Since the
actual root problem is the typecast. The tradeoff between code style and
@annotation style seems more reasonable to me now, either choose the
convenience or the typecast. :-)

-----
http://www.Soluvas.com/ Soluvas - Making eCommerce Work for You 
-- 
View this message in context: http://old.nabble.com/How-to-remove-%22abstract%22-with-AspectJ--tp27617645p27648758.html
Sent from the AspectJ - users mailing list archive at Nabble.com.