Top critical review
16 people found this helpful
Best available documenation on Eiffel
on February 11, 2005
For those who don't already know, Eiffel is a 1990-era object oriented programming language. It is best known as the vehicle for Meyer's "design by contract" methodology, a relaxed version of formal, mathematical proofs of program correctness.
This book sets out to be two things: a user guide and also a specification of the Eiffel language, as it was defined at version 3. It's not quite rigorous enough to be a full spec, but adequate as a user guide. This is not a tutorial for beginning programmers, a very different kind of book, but it says at the outset that it was never meant for beginners. That's fair, since beginners and experienced programmers need quite different kinds of material for learning a language. The organization isn't all I could have asked for, but I could use it for wrting Eiffel programs if I had to.
The one thing that stands out in this book is its lengthy discussion of the typing system. That is well justified. Eiffel has the most complex type system I've seen, including parametric types (like C++ templates), multiple and repeated inheritance, and more than one scheme for creating aliases. Its repeated inheritance mechanism allows class B to claim class A as a superclass twice - like "diamond" inheritance in C++, but without the intermediate steps. That's where renaming comes in, creating ways to refer to the two different A superclasses unambiguously. Also, Eiffel allows a subclass to over-ride a function's return type - just to add flavor to the mix and complexity to the class-type rules. Once you combine parametric types, aliasing, and all the rest, type compatibility becomes a real hairball and is the subject of lengthy discussion. Despite its length, that discussion lacks clarity and examples, so I would expect a lot of ugly surprises if I tried doing serious work in this language.
The one serious omission here is lack of description of LACE - sort of a linker language for Eiffel, with a renaming facility of its own. Java and C# programmers won't even know what a linker is. Good. Since Eiffel requires LACE for just about any nontrivial application, however, something a bit more readable than appendix D would have been helpful. Another important idea is also weak or absent in this discussion: how name spaces are organized for projects so big that duplicate class names become likely. That may be a lack in Eiffel itself, though.
There's a lot to say about Eiffel, good, bad, and just puzzled. I'm not commenting on the language itself, here, except to say that I'm glad more recent languages are simpler, or at least put their complexity elsewhere.
I can't give this a ranking among other Eiffel books, because there are so very few others. It appears adequate as a reference for advanced programmers, but suffers from an inverted organization and thin discussion of some important topics.