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

[tom <tmb at ncal point verio point com x@x.x>]

"Ken Garlington" <Ken.Garlington@computer.org> 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.