[aosd-discuss] "AOP considered harmful"

[Dean Wampler]

Robin,

My reply to Ron's reply covers some of your points. In summary, I 
suggested the straw man proposal that Liskov's SP and contracts 
shouldn't be violated. Instead, modules should be refactored to support 
more flexible contracts that accommodate (and maybe deliberately 
restrain) a range of advices. Also, as Ron suggested, it's very useful 
to consider exceptional conditions as cross-cutting concerns. Of course, 
for those situations where refactoring is not possible, then changing 
the contract, when done judiciously, can be a "good hack".

Do you have a reference to your earlier work on this with Awais? I would 
like to read more on your arguments.  Thanks.

Maybe I'm being too strict about the role of contracts ;) However, I 
would like to see compelling counter examples. Somebody please prove my 
straw man wrong!

dean

Robin Green wrote:
> On Wed, Apr 27, 2005 at 07:57:22PM -0500, Dean Wampler wrote:
> 
>>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.
> 
> 
> Not neccessarily. As Awais and I pointed out some years ago, aspects can
> be used for many different purposes: an aspect might be used to modify the
> behaviour of a class, and thus the contract, completely intentionally! [1]
> 
> Unlike with classes and subclasses, it is possible with aspects to say
> "This aspect should always be woven in to every instance of the class,
> or to every instance of the class that satisfies such-and-such conditions",
> so it is not necessarily incoherent for an aspect to change the contract of
> a method.
> 
> With classes you can make an abstract class, but that can still be extended,
> so substitutability is arguably needed between classes and their subclasses.
> It is _not_ always needed between "unwoven" classes and their "woven" equivalents
> - because often a "woven" class does not have to coexist with its "unwoven"
> parent.
> 
> Ah, but what about tool support? Yes indeed, I personally think we should focus on
> formalising real-world languages or make real-world languages that are
> formalisable (which is what I am trying to do) before we start playing too
> much with tool support for "intentional contract-breaking". ;)
> Have to walk before you can run.
> 

-- 
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]