[aosd-discuss] "AOP considered harmful"

[Curtis Clifton]

On Apr 27, 2005, at 8:42 PM, Awais Rashid wrote:

> Dean,
>
> Interesting point indeed. We are exploring similar ideas. You might be
> interested in the following technical report. It discusses the notions 
> of
> dependency alignment, weak and strong orthogonality:
>
> http://www.comp.lancs.ac.uk/computing/aose/papers/COMP-001-2004.pdf
>
> Awais.

Dean and Awais, thanks for the links.  I'm also exploring similar ideas 
in my dissertation.  In particular, I'm interested in techniques for 
partitioning the concerns described by method and advice contracts.  
The idea is that a method's contract would only specify behavior with 
regard to a particular concern (in some well-defined sense of the term 
"concern").

Advice that manipulated the _same_ concern would have to either follow 
the substitution principle Dean describes, or else be visible from the 
code for the method so that the specification of the advice could be 
composed with the specification of the method.

On the other hand, advice that manipulates a disjoint concern can do 
whatever, so long as it does not change the behavior of the advised 
code respect to that code's domain.

This approach leads to an implicit under-specification of methods.  The 
method's specification describes its behavior relative to the method's 
domain, but the behavior of the method relative to other domains is 
unspecified.

I don't yet have details of this "concern domains" approach in a form 
that I can share.  However, some earlier workshop papers and technical 
reports, co-authored with Gary Leavens, are related to the discussion:

 From FOAL '02 (see the obtuse section on specification composition): 
http://www.cs.iastate.edu/~cclifton/papers/TR02-06.pdf

A tech report derived from the FOAL paper, which refines the language 
features: http://www.cs.iastate.edu/~cclifton/papers/TR02-10.pdf

Another tech report that explores the connections between AOP and 
behavioral subtyping (i.e., the Liskov Substitution Principle): 
http://www.cs.iastate.edu/~cclifton/papers/TR03-15.pdf

Cheers,

Curt

----------------------------------
Curtis Clifton, PhD Candidate
Dept. of Computer Science, Iowa State University
http://www.cs.iastate.edu/~cclifton

>> -----Original Message-----
>> From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On 
>> Behalf
>> Of Dean Wampler
>> Sent: 28 April 2005 01:57
>> To: Ron Bodkin
>> Cc: 'AOSD'
>> Subject: Re: [aosd-discuss] "AOP considered harmful"
>>
>> I've given some thought to applying Meyer's "Design by Contract" (DbC)
>> to aspects and how aspects need to respect the contract of the advised
>> code.
>>
>> The Liskov Substitution Principal applies; If a class is substitutable
>> for an interface, then the class+advice must be, too. This means that 
>> if
>> a method in the class stipulates precondition A (conditions that must 
>> be
>> met on entry to the function) and satisfies postcondition B 
>> (guaranteed
>> results, if the preconditions are satisfied) and invariant C, then
>> before advice needs to be contravariant with respect to A, convariant
>> with respect to B, and invariant with respect to C.
>>
>> "Contravariant with respect to A" means that the advice must 
>> stipulate a
>> contract equivalent to A or /weaker/ than A; if it stipulated a 
>> contract
>> /stronger/ than A, then it won't be substitutable for the class. A
>> weaker contract is okay.
>>
>> "Convariant with respect to B" means that it must guarantee to meet 
>> the
>> postconditions B or /stronger/ conditions (again, to satisfy
>> substitutability, it can't relax the "promise").
>>
>> Finally, any invariants must be respected.
>>
>> I've been working on a paper, which needs a lot of work, that 
>> discusses
>> DbC in more detail (along with other design principles):
>>
>> http://www.aspectprogramming.com/papers/AOPerspectiveOnOOD.pdf
>>
>> dean
>>
>>
>> Ron Bodkin wrote:
>>> [snip]
>>>
>>> Re: the Liskov Substitution Principal and adherence to contracts, I
>> think
>>> most real systems have best efforts informal documentation of 
>>> semantics,
>>> which is far less than a contract. So what does it really mean that 
>>> you
>> can
>>> substitute one subtype for another? How do you know what 
>>> pre-conditions
>> and
>>> post-conditions apply?
>>>
>>> [snip]
>>>
>>> -----Original Message-----
>>> From: Juri Memmert [mailto:memmert at jpmdesign.de]
>>> Sent: Tuesday, April 26, 2005 10:20 PM
>>> To: Bill Burke
>>> Cc: AOSD; Ron Bodkin
>>> Subject: Re: [aosd-discuss] "AOP considered harmful"
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Bill Burke wrote:
>>>
>>> [snip]
>>>
>>>>> I question this in practice in large OO systems. Without tools
>>>>> support, finding the possible subclasses or implementers of 
>>>>> something
>>>>> is quite difficult, so knowing what actual implementation code will
>>>>> execute is hard.
>>>
>>>
>>> Yes and no. Unless you messed up your implementation, the Liskov
>>> Substitution Principle still has to apply. And so you have a general
>> notion
>>> of the contracts the application will abide by. If you did break that
>>> principle, you've already doomed your application to die a slow and
>>> agonizing death.
>>>
>>> [snip]  ...
>>
>> --
>> Dean Wampler, Ph.D.
>> dean at aspectprogramming.com
>> http://www.aspectprogramming.com
>> http://www.contract4j.org
>> I want my tombstone to say:
>>     Unknown Application Error in Dean Wampler.exe.
>>     Application Terminated.
>>     [Okay]    [Cancel]
>>