Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

["Frank Mitchell" <frankm@bayarea.net>]

Steve Merrick wrote in message
<8kh89g$si$1@newsfeed.pit.comms.marconi.com>...
>"tom" <tmb at ncal point verio point com x@x.x> 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