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

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

Jubilation wrote in message ...
>"Frank Mitchell" <frankm@bayarea.net> 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