From john_j_sung@yahoo.com Wed Dec 5 13:59:16 2001 X-UIDL: b67362f98fe9f55bc9026a9cceeaa549 Return-Path: Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by amber.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) with SMTP id fB5IxDH14888 for ; Wed, 5 Dec 2001 13:59:13 -0500 (EST) Received: from dsl092-073-162.bos1.dsl.speakeasy.net (HELO sung02) (66.92.73.162) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Dec 2001 18:59:12 -0000 From: "John Sung" To: "'Doug Orleans'" , "'Karl Lieberherr'" Cc: , , , , , Subject: RE: contracts and AOP Date: Wed, 5 Dec 2001 13:57:22 -0500 Message-ID: <000001c17dbe$acaf1c60$a000000a@speakeasy.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15374.27170.744534.145317@vega.ccs.neu.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Status: RO Content-Length: 2276 I would agree with Doug and Theo. There needs to be distinction between "additional" aspects verses "modification" aspects. If you take a look at DemeterJ, the class dictionary and strategy/visitors are totally othognal, i.e. they don't really modify the semantics of each of those files. There is a dependence in that the actuall implementation, i.e. traversal, will change as class dictionary or strategy/visitors change. The other kind of aspect relationship is the subclassing that Doug mentioned. I would categorize the COOL and RIDL as this type. The information in class graph and behavior files are reinterpreted with the COOL and RIDL context. It's basically making a sigle threaded, single process program to multi-threaded and multi-process program using COOL and RIDL. I'm not so sure about preserving the pre-, post-, and invariants. This might need to be looked at further. The third kind would be the modification aspect. It's where you modify basic the behavior of what's already there. In AspectJ, you can add around methods to replace the different methods calls with your own. This leads to change in the fundamental behavior of the program, or the semantics of the program changes. So, is there work being done on aspectual categorization? John -----Original Message----- From: Doug Orleans [mailto:dougo@ccs.neu.edu] Sent: Wednesday, December 05, 2001 1:41 PM To: Karl Lieberherr Cc: skotthe@ccs.neu.edu; edwards@intranet.com; johan@ccs.neu.edu; john_j_sung@yahoo.com; neerajsangal@mediaone.net; robby@ccs.neu.edu; wupc@ccs.neu.edu Subject: Re: contracts and AOP Karl Lieberherr writes: > Doug proclaimed the following guidelines: > > Adding an aspect should not change (invalidate?) > pre- and post- conditions of existing code. > > Adding an aspect should lead to a behavioral subtype. I think "proposed" is a better word than "proclaimed". Or more like, "hypothesized". I think Theo is right, it depends on the aspect. Perhaps that would be a way to categorize aspects: those that preserve contracts and those that invalidate contracts, without making a value judgement on the latter category. --Doug _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com