This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

An interesting prospect

Posted by Mike Mannion on 03 Dec 1998, 1:00 AM

John Rivet-Carnac Wrote
> Although the semantic constraints may differ, there is still only one implementation, which would presumably have to be written to comply with all the constraints from all the interfaces which have the same method. If the constraints are mutually exclusive, then you cannot implement the method - i.e. the interfaces are mutually exclusive, so you cannot mix them. I am no expert in the expression of semantic constraints, but wouldn't it be possible for the compiler to check that the constraints for the same method in two interfaces are not conflicting?

This is definitely an interesting approach to addressing conflicting semantic constraints caused by having identical method signatures. Indeed, there seem to be a number of alternatives:

1) Provide a method signature renaming facility (like Eiffel's), although this has the disadvantage of having to introduce keywords into the language, in addition to the new constructs required to express semantic constraints.

2) Disallow semantic constraints from more than one "source" i.e. from more than one class/interface. Whilst simple, this (coincidentally?) bares resemblance to the decision to restrict Java to single implementation inherence, in that is simplifies compiler and language design at the expense of expressive power.

3) Your suggestion: Determine potentially conflicting Boolean expressions by comparing assertion expressions at compile-time, and rejecting conflicting constraints.

I�m certain (but cannot prove - any logicians out there?) that the third variation would only be possible for a subset of all possible assertion expressions. Of course, it depends on the language we use to express assertions. If we use simple prepositional logic, then I guess there is a good chance we can check for conflicts. But if we want to be able to use functions in assertion expressions - then I guess not.

The approach taken by the iContract tool - a tool which supports DBC in Java merges assertions from inherited interfaces in the following way: preconditions are ORed so that either interface A�s preconditions or interface B�s preconditions must be satisfied. Postconditions and invariants are ANDed so that both interface A�s postconditions/invariant and interface B�s postconditions/invariant must be satisfied.

Whatever solution is ultimately chosen (now that�s optimism!), it�s primary focus should be on supporting the expression of correct behaviour. Being able to identify conflicting behaviour at compile-time would certainly be nice to have, but I don�t regarded it be absolutely necessary.