Re: [aspectj-users] Possible AJ change: Read this if you usepackage (def

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

I would rather live with implementation restrictions than limit the spec of aj from useful capabilities. Abstract aspects with abstract itd methods are useful like protected template methods are in java. Even better would be protected itd's. I vote for keeping this feature and improving it over time. 

Longer term generating aj attributes to better support multiple separate aj compiles. In time, aj projects will use aspectj as their programming language not an adjunct to java. 
-----Original Message-----
From: Bo Yi <boyi@xxxxxxxxxx>
Date: Fri, 30 Sep 2005 14:53:42 
To:aspectj-users@xxxxxxxxxxx
Cc:aspectj-users-bounces@xxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Possible AJ change: Read this if you use
	package	(default) visible abstract ITDs?

I vote for package level visibility. 
 
If an abstract ITD has to be public as one of the proposals in Bug Report 72834, we would have to enforce all its subclasses to implement this abstract method. Otherwise, one can use introspective reflect to get the Method object and invoke it on its subclass. But that method may not be overridden (implemented) in the subclass at all. 
 
If it is declared at package level, other classes can not invoke the Method even though it may be able to get its signature. 
 
Regards, 
 
Bo 
----------------------------------------------------------
   Dr. Bo Yi
   WebSphere Development & Testing
   IBM Toronto Lab 
   A2-713/Q2Z/8200/MKM
   8200 Warden Ave. Markham ONT. L6G 1C7
   Phone: 905-413-4819 
   Tie Line: 969-4819
   E-Mail: boyi@xxxxxxxxxx
 
 
 
 Charles Zhang <zhangcharles@xxxxxxxxx> 
Sent by: aspectj-users-bounces@xxxxxxxxxxx 
09/30/2005 01:03 PM 
Please respond to
 aspectj-users 
 
To Andy Clement <andrew.clement@xxxxxxxxx>, aspectj-users@xxxxxxxxxxx 
cc 
Subject Re: [aspectj-users] Possible AJ change: Read this if you use package        (default) visible abstract ITDs? 
 
 
 
 
>From my (a user) point of view, our projects do find
 package level visibility useful. That is, we introduce
 methods or fields only visible in aspect packages.
 They cannot be pulic since it will leak the
 concern to the outside. They cannot be private
 because we want other non-child aspects in the same
 package to know about them. So I vote no for making
 it an error, if I didn't misunderstand the issue. 
 
 Charles
 
 --- Andy Clement <andrew.clement@xxxxxxxxx> wrote:
 
 > 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-users mailing list
 > aspectj-users@xxxxxxxxxxx
 >
 https://dev.eclipse.org/mailman/listinfo/aspectj-users
 > 
 
 
 Yawn !!
 _______________________________________________
 aspectj-users mailing list
 aspectj-users@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/aspectj-users
 
 _______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Sent wirelessly via BlackBerry from T-Mobile.