From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Frank Mitchell" Subject: Re: Aspects (Re: Interesting thread in comp.lang.eiffel) Date: 2000/07/12 Message-ID: <8ki7ct$8q2$1@news.bayarea.net>#1/1 X-Deja-AN: 645538744 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <396502D2.BD8A42E7@earthlink.net> <39654639.B3760EF2@eiffel.com> <85Fa5.11419$7%3.818927@news.flash.net> <8kh89g$si$1@newsfeed.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@bayarea.net X-Trace: news.bayarea.net 963420381 9026 205.219.85.192 (12 Jul 2000 16:46:21 GMT) Organization: Bay Area Internet Solutions NNTP-Posting-Date: 12 Jul 2000 16:46:21 GMT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-12T16:46:21+00:00 List-Id: Steve Merrick wrote in message <8kh89g$si$1@newsfeed.pit.comms.marconi.com>... >"tom" wrote in message >news:pb8k8ersvvs.fsf_-_@aimnet.com... > >> Have people in the Eiffel community looked at aspects? >> What do you think? > >I've long been interested in Eiffel, but not (yet) had the chance to use it >professionally. :-( The obvious attraction of Eiffel (to me) is DBC. I too >would be very interested to hear the views of the Eiffel community on >aspects. I must admit I hadn't realised that aspects provided DBC, or some >equivalent. I think it's safer to say that aspects can simulate contracts, although I don't think it's a good idea. Contracts are meant to be ubiquitous; ideally every routine should have one. Aspects, on the other hand, attach to the "component program" -- the collection of components that express functionality -- through "join points", such as class and routine names. Using aspects for all contracts means typing class and routine names twice ... which wasn't a good idea for documentation or method signatures in the original design of Eiffel (or Java, or other languages). Aspects express design considerations that transcend and distort normal programs, such as concurrency, memory usage, and security. It makes sense to give aspects contracts that relate to those concerns, or to express those aspects declaratively as contracts (if that translates to real code, not assertions) ... but I don't believe all contracts belong in the aspect side of the program. Frank