Good view: From: "Gavin Grover" Date: Sun, 10 Dec 2000 13:46:58 PST Maybe the distinction between an introduction and an advice in an aspect can never be clearcut for anything but the simplest cases, ie, those cases you've already put into AspectJ. Introducing exception throws would require the use of pointcuts with the introduction/advice. Maybe it's useful to think of before, after, around, introduction, and any subsequent language additions as alterations, some of which require pointcuts, some make changes to the class type, and some both require pointcuts and make type changes. An aspect would then comprise pointcuts and alterations. -- Karl From users-admin@aspectj.org Tue Dec 12 12:15:21 2000 Return-Path: Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by amber.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) with SMTP id eBCHFJX23007; Tue, 12 Dec 2000 12:15:19 -0500 (EST) Received: from aspectj.org ([209.233.50.12]) by alpha.xerox.com with SMTP id <60904(4)>; Tue, 12 Dec 2000 09:14:49 PST Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by aspectj.org (8.9.3/8.8.7) with SMTP id JAA21166 for ; Tue, 12 Dec 2000 09:21:21 -0800 Received: from airport.parc.xerox.com ([13.1.137.1]) by alpha.xerox.com with SMTP id <60852(1)>; Tue, 12 Dec 2000 09:13:27 PST Received: from havnor.parc.xerox.com (idea.parc.xerox.com [13.1.100.148]) by airport.parc.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YQ0N8MST; Tue, 12 Dec 2000 08:47:22 -0800 To: AspectJ users Subject: Re: introducing exception throws, and more on introductions References: From: Erik Hilsdale Date: Tue, 12 Dec 2000 08:47:05 PST In-Reply-To: "Gavin Grover"'s message of "Sun, 10 Dec 2000 13:46:58 PST" Message-ID: Lines: 286 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aspectj.org id JAA21167 Sender: users-admin@aspectj.org Errors-To: users-admin@aspectj.org X-Mailman-Version: 1.0rc2 Precedence: bulk List-Id: X-BeenThere: users@aspectj.org Status: R Content-Length: 11741 Yep, a lot of these are definitely post 1.0 items, but we're hoping we can do the simpler ones (throws clauses, in particular) before the 1.0 release. Right now we're leaning toward implemengint throws clause manipulation through the introduction framework rather than the advice/pointcut framework. as> Can you introduce methods and non final non static member as> variables into interfaces in aspectJ)? You can, but it doesn't affect the type signature of the interface. That is, it works by making the introduction in the topmost implementing classes of the interface. This is something that we're thinking about changing in our tinkerings with introduction, and would love some feedback on. as> Is there also a kind of a remove hide in the aspectJ-language as> (the opposite off introduce) of the public methods in the as> language? gg> (1) I can foresee a need to remove a base interface or class gg> from an extended interface/class. For example, in changing gg> classes from local-use to remote-use: gg> introduction SomeService { gg> remove extends Serializable; gg> extends Remote; gg> } gg> I know this particular example code should work if the removal gg> wasn't done, but removing Serializable is clean, and there are gg> probably occasions when removing a particular base class is gg> essential. Not yet. This is almost certainly a post-1.0 feature. gg> (2) If base classes can be added and removed via introductions, gg> there could be a need for a CASTS aspect, which gets called gg> whenever a class instance is casted to another class or gg> interface, or another particular class or interface. I could see CASTS as an interesting primitive pointcut designator, but I can imagine it being very confusing for users, since it would probably be designed NOT to catch upcasts (a.k.a. "free" or "unchecked" casts), but only to catch those points in execution corresponding to the CHECKCAST bytecode. I'm not sure whether it would be used enough to stick it in the language, though. gg> As well as the outright removing of methods/variables from a gg> class, being able to change from any visibility to any other gg> visibility for a method/variable could be useful. When coding, I gg> often have to go through the code later and make bulk changes gg> from package-level to public, because class packaging is often a gg> decision made later on in the coding process. (It's one of those gg> tedious things like Tracing and Error-handling, which AOP has gg> solved.) Being able to easily toggle between two visibilities gg> for groups of related methods may be useful. Perhaps visibility gg> itself could be thought of as an aspect when it's possible to gg> group members/variables together succinctly into pointcuts. This kind of thing seems to be more of a one-shot change rather than a serious modularity problem. I personally am wary of bringing AspectJ further down the road of a tool for easing program development changes rather than as a tool for expressing cross-cutting concerns of actual programs. However, there are definitely visibility issues with introduction that we could be doing better. -erik ============================== Previously... From: "Gavin Grover" Date: Sun, 10 Dec 2000 13:46:58 PST Maybe the distinction between an introduction and an advice in an aspect can never be clearcut for anything but the simplest cases, ie, those cases you've already put into AspectJ. Introducing exception throws would require the use of pointcuts with the introduction/advice. Maybe it's useful to think of before, after, around, introduction, and any subsequent language additions as alterations, some of which require pointcuts, some make changes to the class type, and some both require pointcuts and make type changes. An aspect would then comprise pointcuts and alterations. More on introductions... (1) I can foresee a need to remove a base interface or class from an extended interface/class. For example, in changing classes from local-use to remote-use: introduction SomeService { remove extends Serializable; extends Remote; } I know this particular example code should work if the removal wasn't done, but removing Serializable is clean, and there are probably occasions when removing a particular base class is essential. (2) If base classes can be added and removed via introductions, there could be a need for a CASTS aspect, which gets called whenever a class instance is casted to another class or interface, or another particular class or interface. (3) Changing the list of parameters to a method might be useful, perhaps to introduce/advise an extra Object at the beginning of the argument list, and to insert some object (such as the calling object) as the extra parameter via the CALLS aspect when the method is called. Inner classes are implemented like this, by inserting the non-static containing objects as extra (invisible) parameters when the inner class is constructed. This facility could be used (or misused) to make some objects available globally by making them ripple down through method calls to where they're needed. (4) Arno wrote: Is there also a kind of a remove hide in the aspectJ-language (the opposite off introduce) of the public methods in the language? As well as the outright removing of methods/variables from a class, being able to change from any visibility to any other visibility for a method/variable could be useful. When coding, I often have to go through the code later and make bulk changes from package-level to public, because class packaging is often a decision made later on in the coding process. (It's one of those tedious things like Tracing and Error-handling, which AOP has solved.) Being able to easily toggle between two visibilities for groups of related methods may be useful. Perhaps visibility itself could be thought of as an aspect when it's possible to group members/variables together succinctly into pointcuts. I know these are all things that won't make it into v1.0, but they've arisen from my very initial experimentation of AOP with AspectJ. Gavin Grover -----Original Message----- From: users-admin@aspectj.org [mailto:users-admin@aspectj.org]On Behalf Of Schmidmeier, Arno Sent: Friday, 8 December 2000 9:23 PM To: 'Erik Hilsdale'; users@aspectj.org Subject: AW: introducing exception throws please appoligise, if I did not understand your mail or aspectJ to the required depth. But there are several question and anotations open for me. Arno > -----Ursprüngliche Nachricht----- > Von: Erik Hilsdale [SMTP:hilsdale@parc.xerox.com] > Gesendet am: Montag, 4. Dezember 2000 19:55 > An: Gavin Grover > Cc: users@aspectj.org > Betreff: Re: introducing exception throws > > > Dealing with checked exceptions is something that we're still dealing > with in the design. One thing that keeps hampering us is that we > haven't come to a firm conclusing as to whether the checked > declarations are a kind of introduction or a kind of advice. [Schmidmeier, Arno] From my understanding it is sometimes an introduction and sometimes it is an advice, it depends totally on the usage. However How I would deal with it in aspectJ I do not know. > It feels introduction-like in that it deals with the type system (or > what I call the type system... the static constratint system of Java > in an case), which is one of the powers of public introduction. > Changing the throws declarations of a method affects how other bits of > code view objects of that type. [Schmidmeier, Arno] Yes, that is my understanding, so it is a kind of introduction for me. > However, it has some characteristics of advice as well, in that it > deals with a finer level of granularity than that of class or > interface: we want to introduce these new "throws" constraints on > individual method signatures. [Schmidmeier, Arno] Imagine a function with following signature: public void foo(). Can you change this function with following signature just with advices? public void foo(int arg) If yes, it is a kind of advice. In any other case not from my understanding. e.g. you have the method public void foo(); and you change it to the method public void foo() throws CheckedException, then you change the kind of return type from ({void} to {void or thrown CheckedException}, which is a part of the signature. (However Java does not allow return type overloading, but we are discussing the features of a different language) > Note that you might want to _remove_ throws constraints from > signatures as well, if you handle the checked exception with around > advice. [Schmidmeier, Arno] _removing the throws constraint is still a kind of introduction for me, if the caller need not or must not check the exception anymore. Note: It is an advice, if the caller still has to add a try{}catch block around the method. in other words the advice block declares that it can throw the exception, but does not throw it, because it handles it internally. > So the short answer is, no, you can't do this yet in AspectJ. We > realize that it's a usability hole in the language that we're going to > have to work on pretty soon. > > -erik > [Schmidmeier, Arno] Can you introduce methods and non final non static member variables into interfaces in aspectJ)? Is there also a kind of a remove hide in the aspectJ-language (the opposite off introduce) of the public methods in the language? ============================== Previously... From: "Gavin Grover" Subject: introducing exception throws Date: Wed, 15 Nov 2000 20:10:49 PST Hi AspectJ team While using AspectJ to try to put everything associated with the RMI-remotability of classes and interfaces into a separate aspect, I'm stuck on whether there's a way of introducing the throwing of RemoteExceptions to the members. For example, for an interface and implementation that can be used locally... public interface SomeService { public String someMethod(int x); } public class SomeServiceImpl implements SomeService{ SomeServiceImpl() { super(); } public String someMethod(int x) { //some code } } I'd like to be able to introduce everything to enable them to be used remotely via RMI in the one aspect... aspect RemoteIntroductions { introduction SomeService{ extends Remote; } introduction SomeServiceImpl{ extends UnicastRemoteObject; } // this is the sort of code I'd like the ability to add... introduction SomeService.!private * *(..) && SomeServiceImpl.!private * *(..) { throws RemoteException; //...so every method and constructor would throw this exception } } Is there some way to do what I'm trying to do using advices? If not, are introductions of exception throws coming anytime soon? (2) Of course, if it's possible to do the above, the next thing I'd be looking at is whether it's possible to write a generic aspect to introduce RMI-remoteness to a group of interface-implementation pairs. Something like... aspect RemoteIntroductions of eachclass(SomeService && SomeOtherService) { introduction *{ extends Remote; } introduction *Impl{ extends UnicastRemoteObject; } introduction *.!private * *(..) && *Impl.!private * *(..) { throws RemoteException; } } Cheers, Gavin Grover __________________________________________________ AspectJ users mailing list - users@aspectj.org To be removed send mail to users-admin@aspectj.org or visit http://aspectj.org/lists