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/14 Message-ID: <8kmjo3$s1j$1@news.bayarea.net>#1/1 X-Deja-AN: 646241906 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-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@bayarea.net X-Trace: news.bayarea.net 963564099 28723 205.219.85.203 (14 Jul 2000 08:41:39 GMT) Organization: Bay Area Internet Solutions NNTP-Posting-Date: 14 Jul 2000 08:41:39 GMT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-14T08:41:39+00:00 List-Id: Jubilation wrote in message ... >"Frank Mitchell" wrote in message >news:8ki7ct$8q2$1@news.bayarea.net... >> 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. I guess I didn't emphasize the contrast. In AOP, as I understand it, there are two conceptual entities: components, which express the functionality of the system, and aspects, which express far-reaching design decisions that would otherwise be scattered all over the code. In DBC, on the other hand, the contract is as integral to a routine as its parameters and return type. Defining the contracts in a separate conceptual entity -- whether defined using files or some sort of "model database" -- will require either the person or the tools to juxtapose the two to make sense of the routine. Just as the routines to operate on data are colocated with the data fields in OOP because they are closely related, so the contracts are better left colocated with the routines and classes they describe. >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. You can make virtually anything an aspect, but I don't see the use of doing so when inheritance of deferred ("abstract" or "interface") classes allows an equally clean separation of specification and implementation, and when most contracts concern design decisions which are trivial to localize. Frank