[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Possible AJ change: Read this if you use package (default) visible abstract ITDs?

I mean something like:
> 
> abstract class A { }
> 
> aspect X {
>   abstract void A.foo();
> }
...
> I'm proposing to make it an error, depending on any feedback I get
> here, so that you can't 'specify' default visibility for abstract
> ITDs.

See also "info" bug 50195
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=50195

  Only publically introduced members can be overriden 
  by standard Java code.

This is a corollary of the rule that package-private ITD's
are visible only in the same AspectJ compilation.  I'm not
happy with that rule, but it is a clear one that explains a
number of things without resorting to mangling discussions.

In 1.2.1, overriding works if the package-private ITD's and
their package-private implementations are declared in the same 
compile process and the implementations are ITD's.  It does not 
work if the implementation is in a class, or in another compile
process.  If the implementing ITD increases the visibility to 
public, it can access the supertype implementation using super,
and clients can invoke it from pure-Java code, even in a later 
javac compile.  (72834 is about accessing subtype implementations
via the supertype reference.)

You're saying that we shouldn't do the dispatch method because
it wouldn't be effective for other subtypes and later subtypes, 
but we've already punted on things outside the current compilation.

By making abstract package-private ITD's illegal, you remove
the cases where people use package-private implementations in
the same compile process.

I personally prefer to minimize visibility to reduce complexity, 
so I'd like to retain that ability.  I can imagine some pattern
implementations using aspects where you have an abstract method
(like traverse()) and aspects corresponding to different subtypes
handling traversal.  If you don't want other classes to see and
use the traverse() method, then you'd be out of luck with the
new error message.  One of the benefits of package-private pattern
implementations would be using the same method names (like
"traverse()") without fear of method name collision with other 
pattern implementations targetting the same types.

Nor do I think it helps to single out abstract methods.  The issue
is with any package-private ITD, no?  (It's perhaps more likely that
the implementor is outside the compilation process with abstract ITD's.)

Would it be enough to have a lint message for any ITD with 
package visibility, since its scope is effectively limited to that 
compile process (and to aspects for the purpose of overriding)?  
Then users could decide whether they are info/warning/error messages,
depending on whether they understand the issue.  

btw, I would distinguish the case of interfaces; since Java forces
interface declarations to be public, we haven't taken anything 
away from users.

Is the implementation of package-private ITD overriding inhibiting 
some other necessary compiler change?  Would you want to avoid the
dispatcher by doing it on the call side?  (Would that break incremental?)

Wes

P.S. - I should fold the known limitations (i.e., the "info" bugs) 
into the documentation.


> ------------Original Message------------
> From: Andy Clement <andrew.clement@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx, "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
> Date: Fri, Sep-30-2005 2:14 AM
> Subject: [aspectj-dev] Possible AJ change: Read this if you use package (default) visible abstract ITDs?
>
> There are a few bugs around to do with abstract ITDs that have package
> level visibility.  I mean something like:
> 
> abstract class A { }
> 
> aspect X {
>   abstract void A.foo();
> }
> 
> There is a lot of discussion about the problems they introduce in bug 
> 72834:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=72834
> 
> I'm proposing to make it an error, depending on any feedback I get
> here, so that you can't 'specify' default visibility for abstract
> ITDs.
> 
> comments? use cases?
> 
> Andy.
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>