Monday, September 25, 2006


EiffelBase ugliness

EiffelBase is a nice library for the beginner. But when you start working with it, you will see more and more of its ugly faces. I have recently stumbled over a feature in the FILE class that captures two of the major deficiencies at the same time:

Please note that we are not talking about a minor, unimportant feature in an seldomly used class.

The first deficiency is easily visible: we are trying a strengthen a precondition by using require else, something that just does not work in DbC. It is just wrong. It shows that inheritance was used inapproprately (Why is a FILE a SEQUENCE? Why does SEQUENCE not offer an opaque precondition for append? We are talking about two classes from the same library!).

But the second problem is even more irritating: why do we need to pass two closed files? Normally we append to already open files. In my case, I wanted to write some output to a file, append another one, then continue writing, perhaps appending a second one and then close the final result. Instead, I have to write to a file, close it only for append, directly open it afterwards, and so on. EiffelBase does too much for the user, and by this limits the reusablity of the library.


By way of comparison, in SmartEiffel any OUTPUT_STREAM has the feature

append_file(file_name: STRING)

with a precondition that the current stream (i.e. the target) "is_connected" (i.e. is opened).
There is a similar feature in Gobo (with a precondition "is_open_write"), except that instead of passing a file_name (who knows if that file exists or not) we have to pass a stream opened in read-mode. The postcondition says that this input stream has been read to the end.
Yes. I mean, getting "append" right is not too difficult in the first place. GOBO got it right, EPOSIX got it right, SmartEiffel got it right ... why didn't EiffelBase, a library that was even used for publishing a book on library design, get it right?
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?