From lopes@parc.xerox.com Tue Aug 5 15:43:05 1997 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by amber.ccs.neu.edu (8.8.6/8.7.3) with SMTP id PAA01585 for ; Tue, 5 Aug 1997 15:42:57 -0400 (EDT) Received: from sneetch.parc.xerox.com ([13.2.18.231]) by alpha.xerox.com with SMTP id <52219(4)>; Tue, 5 Aug 1997 12:42:23 PDT Received: by sneetch.parc.xerox.com id <177477>; Tue, 5 Aug 1997 12:42:17 PDT Sender: Cristina Lopes From: Cristina Lopes To: dem@ccs.neu.edu Cc: AOPCore.PARC@xerox.com Subject: engineering the aspects Message-Id: <97Aug5.124217pdt."177477"@sneetch.parc.xerox.com> Date: Tue, 5 Aug 1997 12:42:17 PDT Status: R Karl asked me to send out this mail, as a summary of a conversation we had over the telephone. This is about how to _implement_ aspects, and the possibilities you have in engineering the output code. (Terminology: "aspect" is the issue for which you provide the means of separate description (...); "aspect program" (or "aspect module") is the separate description itself) The engineering decision which is the focus of this note is whether you process a class and its associated aspect programs together or in separate. For certain aspects you may not have a choice. However, for the aspects in D (and also for the Demeter traversals?) you do have this choice. Both approaches have advantages and disadvantages. Processing a class and its aspect programs together is good, since you have all the information you need to generate exactly the right code, and, more importantly, no more than that code. However, it has the disadvantage that if you change the aspect program, you have to re-weave the class; and if you change the input class you may have to re-generate whatever auxiliary structures you have for implementing the aspect programs. The other approach is to process classes and aspect programs in separate. The advantages and disadvantages of this approach are exactly the opposite of the first one. That is, this is bad in that when weaving a class you have no information about the particular aspect programs. Therefore you need to prepare for all possible situations. As consequence, you need to weave much more code than it would be necessary if you knew the aspect programs. However, classes and aspect programs become totally independent at the execution level: any changes on aspect programs imply only the re-generation of the auxiliary structures for implementing aspect programs, not the weaving of the class; any changes on the class imply only the re-weaving of the class, not the re-generation of the auxiliary structures for the aspect programs. In my thesis, I follow the second approach. I understand that you guys follow the first. In the beginning, I was also processing everything together, and I still think it's a valid approach. However what made me lean towards the separate processing was that this second approach opens the possibility for shipping executable class code (not source code) and still being able to modify its behavior wrt the aspects, by pluging it a different aspect program. I think this is neat. Although I'm not familiar with the "new" Demeter with Traversal Objects, I suspect that it did the same engineering shift, compared to the "old" Demeter. Or maybe not? If you change some class (say, add an instance variable), what exactly do you need to re-generate now? -Crista From dougo@ccs.neu.edu Tue Aug 5 16:30:48 1997 From: Doug Orleans To: Cristina Lopes Cc: dem@ccs.neu.edu, AOPCore.PARC@xerox.com Subject: Re: engineering the aspects Cristina Lopes writes: > In my thesis, I follow the second approach. I understand that you guys > follow the first. Yes, but I plan to move towards the second approach (separate compilation of input files). It may take a while, though. > Although I'm not familiar with the "new" Demeter with Traversal > Objects, I suspect that it did the same engineering shift, compared to > the "old" Demeter. Or maybe not? If you change some class (say, add an > instance variable), what exactly do you need to re-generate now? Everything. (Although we don't need to re-compile .java files that haven't changed.) Which is why I want to move towards separate compilation. --Doug