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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: "Jubilation" Subject: Re: Aspects (Re: Interesting thread in comp.lang.eiffel) Date: 2000/07/14 Message-ID: #1/1 X-Deja-AN: 646182116 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> <8ki7ct$8q2$1@news.bayarea.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Trace: read2.inet.fi 963547577 212.213.248.88 (Fri, 14 Jul 2000 07:06:17 EET DST) Organization: Sonera corp Internet services X-MSMail-Priority: Normal Reply-To: "Jubilation" NNTP-Posting-Date: Fri, 14 Jul 2000 07:06:17 EET DST Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-14T00:00:00+00:00 List-Id: A few months ago I gave a talk at Nokia Research Center about generative programming and one of my demos was to implement DBC with AspectJ. There are only two differences I can find: 1. syntax, Eiffel in easier to read, AspectJ requires typing names twice. 2. Possibility to do more good and harm with AspectJ. In other words, I cannot imagine a single thing that you can do with Eiffel style DBC and you can't do with AspectJ. Can you? More comments embedded Please drop the 1 away from my email address if you reply -- "Frank Mitchell" wrote in message news:8ki7ct$8q2$1@news.bayarea.net... > > 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 was deeply dissappointed when java came out without DBC, but the xerox AOP group has done incredible job to fix the situation. > > > >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 Precisely like me! > >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. Can you please explain what is the actual difference? I just can't see any. > 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). This is mainly due to our tradition of using files as an implementation mechanism. A more versatile source code repository would solve many other problems too. > > 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. Well, I believe that Eiffel DBC is just a limited subset of AOP,just like a hard wired string type in a language is a limited subset of OOP. > > Frank > Kari