[1037] in java-interest
Re: Assertions in Java
daemon@ATHENA.MIT.EDU (Andrew Carlson)
Thu Aug 17 08:57:52 1995
Date: Thu, 17 Aug 1995 08:51:19 +0000
From: andycarlson@attmail.com (Andrew Carlson)
In-Reply-To: your message <199508161903.MAA01912@soda.CSUA.Berkeley.EDU> of Wed Aug 16 12:03:43 -0700 1995
To: johnm@CSUA.Berkeley.EDU (John D. Mitchell), java-interest@java.sun.com
>[...if + flag vs assert...]
>How about something like:
>class TA {
> static final boolean debugMode = true; // or false
> ...
> public void checkMe {
> if (debugMode) {
> // Code of 'assert' here...
> }
> ...
> }
> ...
>}
Yep, that should work. I use ASSERT a lot in C++, so think I would prefer a
bit of 'syntactic sugar' to make them a bit easier to write (and read) though.
>> [Eiffel style Preconditions, Postconditions & Invariants]
>> >How so? The interfaces in Java only specify methods and types (and
>> >constants). There's no state information to base the conditions on.
>>
>> In my opinion, the behaviour of a class (and in java, an interface too)
>> should be fully definable in terms of its public interface. The
>> conditions could therefore be based on the results of public interface
>> functions.
>Hmm... You're using the word 'interface' as it's used in languages other
>than Java. "Interfaces' in have a very specific meaning. They *are* the
>embodiment of what people are (usually) pining for in those other languages
>(whether they know it or not :-).
I agree, the English language does not have enough words!
>Since the 'interfaces' in Java exist precisely for the specification of
>'behavior', there is *no* state information in them (as that would be
>violating encapsulation and placing 'structural' constraints on the classes
>which conform to that interface).
Agreed.
>The Pre- and Post-conditions in e.g., Eiffel exist *within* each class and
>are able to peek in on the state (which they must have or there is nothing
>for them to be used on except for message arguments and their return
>values (and yes, those two sorts of things could be checked in Java
>interfaces (which may or may not be worth the cost of implementing))).
You are right, Eiffel assertions can access the state directly whereas java
assertions at the interface level could not. In answer to this I would
reiterate my previous point that behaviour should be definable in terms of
things that a classes or interface's client can see, namely public methods.
Interface level postconditions could thus be based on calls to query methods
also defined in the interface.
Class level assertions could have access to the state, these would serve to
define the behaviour of the class at a finer level of detail, with full
knowledge of the specifics of the class.
>> Lifting an example from Bertrand Meyer's OO Software Construction Book,
>> the postcondition for a push operation on a stack involves an assertion
>> that the object at the top of the stack (accessible via a query method)
>> is the parameter to the push operation. Such a condition says (and
>> enforces) much more about what a method DOES than simply relying on the
>> method name and parameter types.
>Exactly. This relies on internal knowledge about the *implementation* of
>the class to validate that class's behavior. A truly generic (Java-esque)
>'interfacee' has no inherent implementation. Perhaps it would help to
>think of Java interfaces as being pure virtual/abstract classes.
I disagree, the presence of a 'top' query method does not violate
encapsulation and so does not constitute relying on internal knowledge of the
implementation. Yes, there should be no inherent implementation but that does
not preclude making statements about what the interface's clients can expect
the interface methods to DO.
Everyone presumably agrees that it is possible to describe what an interface
method is supposed to do (otherwise documenting the interface would become a
pretty difficult exercise). I view the use of invariants and
pre/postconditions as an extension of this concept, but in a way which can be
enforced by the language.
>P.S. I wonder if Meyer considers Java to be evil like C? :-? :-)
Probably, but that doesn't mean he never has any good ideas :-)
Andy.
----------------------------------------------------------------------
Andy Carlson. AT&T ISTEL Tel: +44 1527 494358
E-Mail: andycarlson@attmail.com Fax: +44 1527 494318
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
