[
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
>