[1000] in java-interest
Re: Assertions in Java
daemon@ATHENA.MIT.EDU (John D. Mitchell)
Wed Aug 16 18:16:27 1995
Date: Wed, 16 Aug 1995 12:03:43 -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-178>
Andrew Carlson writes:
[...if + flag vs assert...]
> I think I get the gist of what you are suggesting. Is this something that
> can be done with java as it stands?. If so, could you possibly give an
> example to clarify things?
How about something like:
class TA {
static final boolean debugMode = true; // or false
...
public void checkMe {
if (debugMode) {
// Code of 'assert' here...
}
...
}
...
}
> [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 :-).
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).
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))).
> 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.
Hope this helps,
John "Lisp in English" Mitchell
P.S. I wonder if Meyer considers Java to be evil like C? :-? :-)
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
