I do not know much about Eiffel (and I can't stand its Pascal-like syntax...), but the Eiffel feature that I like is design by contract. Design by contract means that function interfaces, the APIs, are seen as a contract between the creator and the user. In most languages this contract is mostly written down in the documentation. Eiffel has them written in the source code. It is also possible to do this in a language like Java, but Java's syntax needs a small modification to make this really comfortable. Let's take this function as an example:
/**
* Computes the speed in meter per second from the given distance
* and time. The time can be given in seconds, minutes or hours,
* depending on the content of timeUnit.
* @param distance the distance in meters, always >=0
* @param time the time, either in seconds, minutes or hours, depending
* on timeUnit. Must never be <=0.
* @param timeUnit the unit of the time. Can only be "s" for seconds,
* "min" for minutes or "h" for hours. Other strings are
* not allowed
* @return the speed in m/s. Guaranteed to be always >= 0.
*/
float computeSpeed(float distance, float time, String timeUnit) {
if (timeUnit.equals("s"))
return distance / time;
else if (timeUnit.equals("min"))
return distance * 60 / time;
else
return distance * 3600 / time;
}
This example will work fine, as long as the user does not violate the API contract. But if the user breaks the contract, the function will either crash (time == 0 causes a division by zero), violate its contract (negative return value if distance or time are negative) or silently return a wrong result (unknown unit in timeUnit).
What Eiffel does is having a special syntax for assertions that are executed before and after the actual function. You can find out more about Eiffel's syntax here. When writing in a language like Java, assertions in the function head are easy to do with either 'assert'-statements or a couple of 'if's. I prefer the latter for argument checks in APIs, since a assert will not produce an error message that is useful for the user: only the function's developer knows the internals of the function and thus will be able to understand the assert's error message. For the return value 'asserts' are ok, because every error in the return value is a bug in the implementation. The problem with assertions for the return value is that they are quite ugly if your function has more than one return statement and they blow up the code:
float computeSpeed(float distance, float time, String timeUnit)
throws IllegalArgumentException {
if (distance < 0)
throw new IllegalArgumentException("distance must not be < 0");
if (time <= 0)
throw new IllegalArgumentException("time must be > 0");
if (timeUnit.equals("s")) {
float r = distance / time;
assert r >= 0;
return r;
}
else if (timeUnit.equals("min")) {
float r = distance * 60 / time;
assert r >= 0;
return r;
}
else if (timeUnit.equals("h")) {
float r = distance * 3600 / time;
assert r >= 0;
return r;
}
else
throw new IllegalArgumentException("Unknown value in timeUnit");
}
The code can be simplified using a try/finally, but the syntax is not much shorter (I know that the try/finally does not make much sense in this example, but when the function modifies an object it is often neccessary that you check the object when the code threw an exception):
float computeSpeed(float distance, float time, String timeUnit)
throws IllegalArgumentException {
if (distance < 0)
throw new IllegalArgumentException("distance must not be < 0");
if (time <= 0)
throw new IllegalArgumentException("time must be > 0");
float r = 0;
try {
if (timeUnit.equals("s"))
r = distance / time;
else if (timeUnit.equals("min"))
r = distance * 60 / time;
else if (timeUnit.equals("h"))
r = distance * 3600 / time;
else
throw new IllegalArgumentException("Unknown value in timeUnit");
}
finally {
assert r >= 0;
}
return r;
}
A more elegant way to solve the problem is to extend the Java language a little bit and to add a feature that I call 'method finallys'. They work like the 'finally' clause of a 'try' statement, but use a function body and allow the inspection of the function's return value. The syntax would like this:
float computeSpeed(float distance, float time, String timeUnit)
throws IllegalArgumentException {
if (distance < 0)
throw new IllegalArgumentException("distance must not be < 0");
if (time <= 0)
throw new IllegalArgumentException("time must be > 0");
if (timeUnit.equals("s"))
return distance / time;
else if (timeUnit.equals("min"))
return distance * 60 / time;
else if (timeUnit.equals("h"))
return distance * 3600 / time;
else
throw new IllegalArgumentException("Unknown value in timeUnit");
}
finally (float r) {
assert r >= 0;
}
The 'method finally' makes it possible to check the return value and optionally also the object's state when the function did not throw an exception. To allow the check for void functions I would suggest the syntax
void methodname() {
}
finally (void) {
}
and for checks that are always executed, even when the function threw an exception, the syntax
void methodname() {
}
finally {
}
And, of course, it should be possible to use both 'finally' variants for a single function.

A question of will
Well, at my work, we did programming by contract since at least 10 years. Using preprocessor macros (yes, I know, anatema for most, but very convenient for this kind of things). A full set of preconditions, postconditions, invariants, default construction detectors and object creation/destruction cookies. Extremely useful. I couldn't program without anymore. Not for numeric libraries anyways. It's a different story for e.g. GUI development, because the development (non-optimized) mode of the code is quite heavy (up to 10 times slower than optimized mode).
Anyways, if you like this kind of strong features in a language, take a look at D.
My 2p
I read some really interesting articles today from Guillaume Laurent. Particulary one about how languages slowly grow to allow the simple expression of the latest proven concepts. This seems very much along the lines of why you like what they have in Eiffel.
I did some of the online MIT lectures a few months back and they had their own JavaDoc extensions for allowing a more natural expression of this kind of stuff.
This is probably your point anyway, but if I was King, the Java syntax would allow me to express this contract as:
float >= 0 computeSpeed(float distance >= 0, float time > 0, String timeUnit) { if(timeUnit.equals("s")) return distance / time; else if (timeUnit.equals("min")) return distance * 60 / time; else return distance * 3600 / time; }Oops!
Sorry, I didn't mean to squeeze in like that! This is my first posting in this area.
So, how about C-based languages ?
So, how do you work out that in C/C++ ? C itself is fairly limited but what's cool is that macro allow quite powerful and nasty hacks.
Let's have a stab at your example:
float computeSpeed(float distance, float time, QString timeUnit) { CONTRACT_ARG( distance < 0, "distance must not be < 0"); CONTRACT_ARG( time <= 0, "time must be > 0"); float r = 0; if (timeUnit.equals("s")) r = distance / time; else if (timeUnit.equals("min")) r = distance * 60 / time; else if (timeUnit.equals("h")) r = distance * 3600 / time; else CONTRACT_ARG_ERROR( "Unknown value in timeUnit"); CONTRACT_RETURN( r>=0, "speed must be positive", r ); }Now the tricky part is about finding the macros to do that. Let's have a try:
#define CONTRACT_ARG( assertion, msg ) { if (! assertion) throw AssertionException( msg ); } #define CONTRACT_ARG_ERROR( msg ) { throw AssertionException( msg ); } #define CONTRACT_RETURN( assertion, msg, value ) { if (! assertion) throw AssertionException( msg ); else return value; }The real problem with exceptions in C++ is that there is a lot of complicated stuff to care about (like object deallocation). The good thing is that the syntax is much shorter than in Java.
Designing by contract is a good thing, but I find designing by tests an even better approach. Since I have read one of the extreme programming books, I always write tests before code and it makes a huge difference in my production code. No more bugs. In that case, the contract enforcement is even stronger, because the function is actually called with normal and strange arguments and the results are checked exactly. The real advnatage with the XP approach does not come at the moment you code, but a few days later, when you want to write very complicated tests, of a few month later, when you need to fix a bug, refactor or rewrite part of your code. The tests give you an insurance that you don't introduce more bugs.
Most of the code written above resemble very much the code I use with cppunit. But I find the cppunit approach more powerful because it allows for more thorough testing.
>
Other note, it is possible to design by contract with python:
python contracts. But as I said, it is more powerful to use unittests (which comes builtin with python) to achieve the same thing.
DBC vs Unit tests
Designing by contract is a good thing, but I find designing by tests an even better approach. Since I have read one of the extreme programming books, I always write tests before code and it makes a huge difference in my production code.
The main purpose is not to find new bugs, but a) to locate the bug that you triggered with your tests, b) to get a good diagnosis when an error happens in a deployed application and c) prevent security leaks which are usually caused by unexpected input.
pre-/postconditions
mhh seems like a bad example to me. what about just writing it this way, without the need to extend the language:
float computeSpeed(float distance, float time, String timeUnit) throws IllegalArgumentException {
if (distance < 0)
throw new IllegalArgumentException("distance must not be <
0");
if (time <= 0)
throw new IllegalArgumentException("time must be > 0");
float r
if (timeUnit.equals("s"))
r = distance / time;
else if (timeUnit.equals("min"))
r = distance * 60 / time;
else if (timeUnit.equals("h"))
r = distance * 3600 / time;
else
throw new IllegalArgumentException("Unknown value in timeUnit");
assert r >= 0;
return r;
}
now you have it even shorter than in with the finally stuff. although i think the finally stuff emphazises it more that you have a postconstraint(or -condition, dunno the expression), it would be something making the language "bigger". i don't know if it is worth it, 'cause i never used languages providing such facilities. But if the language is (theoretically) some day extended to supporting it, i would say it would have to provide also an opportunity to express pre conditions in some way (like your time<=0).
Re: pre-/postconditions
You're certainly right about the example, but I didnt want to use a more complex one. In many functions you can't reduce the number of returns without using gotos or making the function more complicated. It also does not help when you need to check the state of the function's object, because then you may have to check even when an exception has been thrown.
it would be something making the language “bigger
>(With pure Qt/C++ it does no
>(With pure Qt/C++ it does not hurt much though, because the lack of exceptions discourages good error handling…).
.
Hu? C++ supports exceptions
What is the reason for postconditions? I can see a value for preconditions to make sure the caller stuck to the contract, but postconditions have to be fullfilled by the function itself, so it only would have a value for debugging(in a way like (unit)tests or something), wouldn't it?
Postconditions & Exceptions
Postconditions are useful when you have guarantees that the type system can not fulfill. E.g. "the number is always between 1 and 100", or "the pointer is never null".