[1058] in java-interest
Re: Assertions in Java
daemon@ATHENA.MIT.EDU (John D. Mitchell)
Thu Aug 17 20:50:27 1995
Date: Thu, 17 Aug 1995 14:56:30 -0700
From: "John D. Mitchell" <johnm@CSUA.Berkeley.EDU>
To: andycarlson@attmail.com (Andrew Carlson)
CC: java-interest@java.sun.com
In-reply-to: <winATT-2.5.1-andycarlson-180>
Andrew Carlson writes:
> >[...if + flag vs assert...]
[...]
> 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.
Can you think of way to do this without going to the (unpleasant) extreme
of a pre-processor?
The only thing that immediately pops to mind is assert/pre/post blocks (ala
the static and synchronized blocks).
[...]
> 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.
I'll sorta buy that. But can these things be mixed? How/when does an
interface assertion get called? When for the class one? What are the
semantics of what happens if they fail? What about side effects? What
about...
I think there's a lot of subtle issues in adding something like thing this.
[...]
> 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.
Okay, I see that point. That's just specifying more behavior (which, of
course, has to be implemented in the implementing class).
> 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.
I'm dubious that it can be so easily dropped into the language but I'll
agree in theory. :-)
Take care,
John
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
