Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 7:35 AM -0800 12/21/01, Brian Hook wrote:
>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).

Unfortunately MI has a bad reputation in C++. Even people who should 
know better like Scot Myers rag on it. But essentially all of the 
problems with MI in C++ are because of virtual base classes. So how 
do you avoid virtual base classes? By avoiding diamond shaped 
inheritance hierarchies.

One way to do this is by using mixin classes. You have your main-line 
classes like Widget or Monster or whatever and then you have mixin 
classes like ReferenceCountedMixin or ObserverMixin or whatever. 
Mixins only descend from other mixins so you never wind up with the 
diamond of death.

This turns out to be a very nice way to design frameworks and, unlike 
Java, you *can* reuse implementation.

>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.

Or they just rely on name commonality. So, you can have a container 
of Foo's and Bar's and still call name() or process() or whatever and 
it will just work, even if there's no common base class.

>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,

I disagree. The division between containers, iterators, and 
algorithms is great. The attention to performance and the performance 
guarantees are great. The ease of use coupled with flexibility and 
extensibility is great. Type checking is great (might as well 
leverage one of the things that C++ does well). The fact that it's a 
compile time library is at least cool because it lets the library 
adapt itself at compile time to the types you're using (eg int's can 
be memcpy'ed).

>it's a bitch to compile, and a bitch to debug.

I'll give you this one. :-)

>Having stepped into STL code on accident, that's just not a 
>neighborhood I want to visit again.

I bet you'd say the same thing about an awful lot of libraries that 
you use though. Unfortunately most of those libraries are compiled so 
that you can't see how poorly they're written. The problem with STL 
is that templates add quite a bit of visual clutter, the better 
implementations have a lot of different cases for things like POD and 
non-POD types, and the most popular implementation looks like (but 
isn't) shrouded.

   -- Jesse