Matthew, I agree that Aspects do not break encapsulation which is why I¹m in the process of adopting them. Taking the larger view, encapsulation can only happen with respect to something. In the OO paradigm, it attempts to be absolute which causes the problem I mentioned previously: the only solution to fixing some problems is for developers to manually break encapsulation by modifying code throughout a system. In the AO paradigm, it recognizes this w.r.t. nature and encourages developers to encapsulate concerns into aspects but allows anything. It also recognizes that rarely do we get the design right the first time so it allows privileged aspects to break the rigid OO encapsulation model.
Since you moved this discussion to the dev thread, I would like to take the opportunity to discuss some enforcements that I¹ve been trying to implement the last few days. The gaping weakness that I see in AJ is its poor expressiveness w.r.t. static enforcement. While I think AOP should allow developers to do what they want, I also think it is a terrific idea to allow architects to design project-specific errors so that people know when they are doing something wrong. I¹m trying to express simple statements like: * All listener methods must be expressed in Listener interfaces * Listening to model X (also package X) may only be coded in package Y by implementing interfaces from package Z > * unless it is coded as an override of a method coded in a package outside my > system that already tangled its concerns * Various other statements of class location and the biggest problems I¹m having are that: * class declaration does not create a join point * thisJoinPartStaticPart cannot be used in error declarations (I¹m just now about to check to see if it will even tell me the information I need to know in order to convert this to a runtime exception) In short, the ability to violate OO encapsulation is awesome; however, it¹s like a nuclear reaction, an uncontrolled bomb or a thoroughly regulated power plant. Does anyone else have experience trying to enforce these kinds of constraints? Am I just trying to push AJ beyond its intended design so I should add CheckStyle or some other piece of technology to my projects? I also see that the S.C.O.P.E. AJ implementation based on ajc is much smarter about making static choices. Is it possible to replace the standard AJ compiler included in AJDT with this one? Since I¹m newly adopting AJ to my projects (and figure I¹ll get enough pushback already), I prefer to deal with the standard limitations if adopting the better compiler means losing all the Eclipse support of AJDT. From: Matthew Webster <[EMAIL PROTECTED]> Date: Tue, 27 Feb 2007 11:15:55 +0000 To: <[EMAIL PROTECTED]> Cc: <[email protected]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: AspectJ and Encapsulation (was [aspectj-users] Q about "adviceexecution" and "declare error") Kevin, I think this discussion also belongs on aspectj-dev. You make a very good point. Most aspects have a well defined purpose and those that "break encapsulation" (I don't think they do but that is a separate conversation about semantics) do so for a reason. If a private field/method needs to be accessed (and there are plenty of good use cases for this) or a private method advised a conventional approach would require the class author to add accessor or template methods. In a large system this will involve several authors and many classes. Besides the obvious code maintenance issue there is one of integrity. With the traditional approach, which supposedly doesn't break encapsulation, any Tom, Dick and Harry can call the new methods. With the AspectJ implementation only the aspect has access. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM United Kingdom Limited Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Kevin F <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 26/02/2007 16:13 Please respond to [email protected] To <[email protected]> cc Subject Re: [aspectj-users] Q about "adviceexecution" and "declare error" Hi Eric, I don¹t mean to butt in on your conversation and may have missed some of the leading conversation; however, I believe the point is this: is it better to implement certain things by making changes throughout the base implementation or to violate encapsulation so that the single concern can be addressed in one place? I know that I¹ve had my share of weeks consulting on different projects where I joined the project and was tasked to analysis exactly the crosscutting concerns addressed by AspectJ through the use of elaborate scripts and manual intervention. In my consulting (usually as the guy called in to rescue a train wreck), it has been common place to a single change in more than 100 files. Any technology can be misused. I can use JNI to circumvent encapsulation, but it doesn¹t mean that JNI should be removed from Java. Kevin From: Eric Bodden <[EMAIL PROTECTED]> Reply-To: <[email protected]> Date: Mon, 26 Feb 2007 09:57:32 -0500 To: <[email protected]> Subject: Re: [aspectj-users] Q about "adviceexecution" and "declare error" Yes, it's exactly this view you mention which I meant. A proper component can be deployed in whatever context. As long as this context adheres to the component's component model, this component is known to work and moreover the outside world can see nothing more but its interface. This is not true for a program that is deployed in the context of a general AspectJ program. The aspects can see and modify anything they like. A class/package/component has no means of hiding implementation details and in fact a lot of aspects rely extracting context information from directly inside those classes, which is IMHO sometimes quite worrisome w.r.t. independent development of both, aspects and base code. Eric On 2/26/07, Matthew Webster < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> > wrote: Eric, >If you want to give static guarantees, it's just painful and that's >what many people are worried about. But you _can_ make static guarantees about the AspectJ program. What you seem to be describing is the trouble with making such guarantees about a Java program that is later deployed and executed as an AspectJ program. My comment about reflection related to privileged aspects but again you can make static guarantees unlike with reflection. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM United Kingdom Limited Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) "Eric Bodden" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 22/02/2007 20:29 Please respond to [email protected] To [email protected] cc Subject Re: [aspectj-users] Q about "adviceexecution" and "declare error" On 2/22/07, Matthew Webster < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> > wrote: > > Eric, > > I was aware of the work on open modules but have not read the papers you refer to. Perhaps I should. However I do not believe any new controls are necessary because Java in conjunction with a runtime modularity framework like OSGi already provides sufficient mechanisms. This is why I am working on AOSGi (http://www.eclipse.org/equinox/incubator/aspects/). <http://www.eclipse.org/equinox/incubator/aspects/).> Oh, sounds interesting. I will have a look at it. > > >I know whole research communities which believe that not being able to > >guarantee any sort of encapsulation by far the largest problem of > >AspectJ. > I not believe AspectJ breaks encapsulation any more than Java reflection. Well, that might be true but a lot of people would say that reflection is bad style for almost everything but a few distinct use cases, too. If you want to give static guarantees, it's just painful and that's what many people are worried about. Eric -- Eric Bodden Sable Research Group McGill University, Montréal, Canada _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ aspectj-users mailing list [email protected] <mailto:[email protected]> <mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/aspectj-users -- Eric Bodden Sable Research Group McGill University, Montréal, Canada _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users______________________ _________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
