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]> 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]> 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/). 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] 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
