Into Eiffel by Ian Joyner (5/5)

Gotos and global variables. Gotos are not needed because the Eiffel style is to write small routines. Global variables are a sign of poor structuring—all Eiffel code must be structured in classes. Once routines, which have already been mentioned, are the concept needed to do away with global variables since once routines give controlled access to shared information. Eiffel also does not need type casts to make up for a flawed type system and, like Java, does not have pointers with their associated problems.

In order to interface to existing software or low-level (inner) software, Eiffel provides external routines. These too can be guarded with pre- and postconditions. The only difference between a normal routine and an external routine is that the do section is replaced by the external keyword and some information on how to link to the external software, but has no instructions.

The Cocoa and Carbon libraries on OS X make extensive use of the external feature to interface. Eiffel Carbon has been designed so that OS X Carbon has a object-oriented wrapping and so the Eiffel interface is more organized than just the raw Carbon API.

If you need to write your own C routines either for performance or direct access to hardware (which you normally should not do since you should call the toolbox), you will call these via Eiffel’s external routines.

That’s about all there is to Eiffel the language. The rest is up to you by using good design of software that Eiffel will help you with, more than any other language, and intelligent use of the Eiffel libraries such as EiffelBase and Cocoa that give you the features that other languages have built in. If you are writing Eiffel on the Macintosh, a very good place to start is to study the Eiffel Carbon library. Carbon shows all the advanced features of Eiffel and how the interface to MacOS can be organized much better than previously possible—such are the possibilities when using Eiffel to design, write and organize your software.