Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 01:56 AM 12/21/2001 -0500, Kent Quirk wrote:
>definitely use a fourth revision. (It appears he wrote a book in 1999 by
>starting from the paper, so you probably have to buy the book to get an
>update.)

I have the book.  It's good, and very length expansion on his previous 
critique.  He does seem to try to be objective, but there is a bit of a C++ 
negative sentiment and a positive Eiffel bias; not so much in absolutes, 
but where he's willing to cut slack, e.g.:

"While C++ does possess feature XYZ, it's a royal pain in the ass to get 
to" vs.
"While Eiffel lacks feature XYZ, it is trivial to work around by blah blah 
blah"

I'm also beginning to see some areas of Eiffel that I'm not sure I'm 
comfortable about (other than the different implementations that aren't 
entire compatible).  For example, Eiffel supports and almost pushes MI 
because they have a model of what inheritance means, even Ian does talk at 
length about the differences between interface and implementation 
inheritance (which is almost never discussed in introductory C++ texts but 
which is absolutely vital to not screwing up a framework design).

In Eiffel, it feels like inheritance is pushed for mix-in style programming 
where you're pulling in multiple implementations instead of multiple 
interfaces.  I personally prefer using inheritance for 
interface/implementation separation, not as an extension for code reuse (I 
use aggregation for the latter).

I think Obj-C and SmallTalk's emphasis on simplicity gives them an 
advantage.  For example, inheritance is discouraged as a form of extension 
by a client.  Areas where you would normally use inheritance they tend to 
push either aggregation or, more likely, delegation.

Have I mentioned that Cocoa is just a joy to work with?

>No overloading.

I dislike overloading.  I think this is a preference thing, but I would 
much rather see:

SetPositionWithVector( ... );
SetPositionWithXYZ( ... );
SetPositionWithTransform( ... );

Than just three different versions of SetPosition().  This is for both 
pragmatic (I want to search for all instances where I set position with a 
vector; I want the environment to choose the right function to start 
hinting to me about the parameter types) and stylistic reasons.  But I've 
heard the counter-argument of "I don't want to remember all those variants" 
and it seems valid to me.  I've just seen it abused, a lot, and it ends up 
making potentially difficult to read or maintain code (not to mention when 
things go to hell with inheritance and default arguments).

>Again, it comes down to favoring readability over writeability
>and eliminating ambiguity.

Yep.

>No nested classes.

I'm with them on this one too, although this is primarily because I dislike 
the entire linkage and file system model that C/C++ impose.  Nested classes 
are nominally private to the enclosing class, yet for some reason when you 
change the nested class you force a recompile of, well, everything that 
includes the specification of the enclosing class.  Blah.

>C: "You can do whatever you want."

Personally I think all the languages let you do whatever you want, so long 
as in the end they let you call out to C for the gritty low level 
stuff.  These days doing what I want isn't an issue, is how I go about 
doing it.  C++ feels like a really bad practical joke.

Take STL. Please.  The only reason I can fathom that people love it so much 
is that it's there (and even then, you have to go get a "real" 
implementation to avoid the scorn of those that laugh when you say you're 
using Microsoft's implementation).  Hey, I don't have to write a map class, 
it's just there!  STL isn't particularly well designed, it's a bitch to 
compile, and a bitch to debug.  Having stepped into STL code on accident, 
that's just not a neighborhood I want to visit again.  STL just seems like 
"Oh, someone wrote some code that's more reusable than the stuff I've 
hacked together over time...cool!" I personally just try to make my code 
reusable.  Go figure.

Brian