Eppur si sugat

[Todd Coram]

Joe Armstrong wrote:

>   Since I have the book in question in my bookshelves I thought I'd check
...
>
>   Part I - is "Issues and principles"
>   Part II - is "Techniques of OO design and programming"
>
>   Part I is general, Part II is stuffed full of Eiffel
>
>   Part I is full of rather general statements about good ways to program.
>

Ah, you must have the first edition... The second edition weighs in at about
1200 pages and greatly expands upon the Eiffel-ness (it even comes with a
"demo" Eiffel development environment --- but never referred to as Eiffel).

>   In part I  there is virtually nothing I disagree with  - and all the
> statements  he  makes  are   equally  applicable  to  *any*  style  of
> programming - just general good advice, equally applicable to C, Java,
> Erlang, Basic, Cobol  you name it - And (virtually)  nothing do do with
> OO (at least not *exclusively* so).

Yes. Those are the comforting bits. It's my favorite OO text because Meyer
speaks his mind, stays away from "fashionable trends" (with the exception of
OO iteself ;-) and generally irritates other non-Eiffel OO advocates.

BTW, Meyer's big claim to fame is "Design by Contract". Although woven
throughout Eiffel, it has been applied to other languages as well.  Design
by Contract specifies that you impose "contracts" (assertive statements)
upon your functions that check a pre-condition (are the parameters correct?)
and post-conditions (did the function produce what I expected?). Also, there
are "class invariants" that make sure that certain variable boundaries are
never broken (e.g. count must never be below 0 and above 255).

I suppose that the preconditions could be accomplished in Erlang by the use
of guards (bear with me, I'm an Erlang newbie), but postconditions and class
invariants have little analog in functional programming (no side-effects!).

But, then, OO is all about side-effects -  (ab)use as many variables as
needed so as long as they are encapsulated! You need postconditions and
class invariants to keep track of what variables may have been accidently
violated...

-- todd