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,FROM_ADDR_WS, 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: tom Subject: Aspects (Re: Interesting thread in comp.lang.eiffel) Date: 2000/07/11 Message-ID: #1/1 X-Deja-AN: 645369773 Sender: tmb@aimnet.com 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> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@verio.net X-Trace: nuq-read.news.verio.net 963386155 206.184.58.115 (Wed, 12 Jul 2000 07:15:55 GMT) Organization: Verio User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Arches) MIME-Version: 1.0 NNTP-Posting-Date: Wed, 12 Jul 2000 07:15:55 GMT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-11T00:00:00+00:00 List-Id: "Ken Garlington" writes: > Unfortunately, all the tool does is eliminate the non-contract part. It > won't convert something like this: > > convert (horizontal_bias: INTEGER): INTEGER is > require > horizontal_bias <= Maximum_bias > > into a plot of horizontal bias vs. ascent angle, or into another form that a > system engineer (as opposed to a software engineer) can understand and use. I think that's a major problem with Eiffel-style contracts: they are scattered throughout the code, and they are limited to assertion checking. To me, it seems that aspects (www.aspectj.org) are actually altogether a better approach. First, aspects let you implement Eiffel-style contracts and separate them out into a separate file. This makes it possible for, say, a system engineer to understand and review them independently. In fact, you can even have separate "cleanroom" development of contracts and actual code, which I would expect to be considerably more robust. Second, aspects let you implement analysis and code understanding tools that are more general than contracts. For example, developing an aspect that could be used to make plots for system engineers would be nearly trivial (a few lines expressing the idea "whenever any method is executed on an instance of this class, note the time, the horizontal bias, and the ascent angle") and without affecting the main body of code. That encourages the development of better testing tools, and it also makes sure that people don't introduce bugs into the main branch of code when writing testing code. Have people in the Eiffel community looked at aspects? What do you think? Tom.