PP>> There is *many* questionable things about C++... Like for
 PP>> example, (regarding pure virtual functions) what happens if I put
 PP>> something else than 0 after the =??? Like in "virtual void fn() =
 PP>> 42"?
 JC> Assuming your compiler works correctly, you get an error message.  The
 JC> syntax in the draft standard makes it clear that if you have an equal
 JC> sign there, only a zero can follow it.  Anything else is an "Ill
 JC> formed program".
This is crazy. Like those so-called "keywords" for casting... Since when am I 
supposed to see "dynamic_cast" and recognise this as a KEYWORD for 
chrissake??? Looks like a damn Pascallian variable name! ;-)) One of the 
suggested "fix" for the "= 0" is to "add" a keyword like this:
#define abstract = 0
So you just do that:
virtual void fn() abstract
Why did they choose to make such a simple thing, obviously crying for a 
simple "flag keyword", such a easy to mess up thing as this "= 0" crap?
 PP>> Also, *not* having multiple constructors,
 JC> I'm not sure what you mean here.  You can overload ctors, but I'm
 JC> pretty sure you're talking about something else.
Ok, in Borland Pascal, we do it like this:
TThisObject = object(TObject)
    constructor Init;
    constructor Load(S: TStream);
    procedure Store(S: TStream);
    [...]
    destructor Done;
end;
The TThisObject.Store method stores the object to the S stream. 
TThisObject.Init is what could be called the "default" constructor (the one 
normally called when creating an instance), and the TThisObject.Load 
constructor is the one that is invoked when the object has to re-create 
itself from a stream, leaving the object in a ready-to-use state, the same 
exact state it was when it was stored. This is the arch-example of multiple 
constructor in Borland Pascal, as this is used throughout the streaming 
mecanism of Turbo Vision.
 JC> Most who'd seriously question that don't really know what they're
 JC> talking about.  I think Booch said it well: MI is a bit like a
 JC> parachute.  You don't need it very often, but when you do need it, you
 JC> REALLY need it.
I have yet to see a case where I'd *REALLY* need it.
 JC> The primary reason many "purists" dislike MI is simply that it
 JC> isn't part of Smalltalk.  However, it's worth noting that many of
 JC> the major Smalltalk vendors really DO implement it.  For instance,
 JC> when Digitalk was working on their Parts/Workbench project, they
 JC> ended up adding in a form of MI because they couldn't come up with
 JC> satisfactory solutions without it.  IIRC, IBM and PARCPlace have
 JC> both done more or less the same things.  They don't really publish
 JC> much about how to do MI, but it's there, and they use it when they
 JC> need to.
I don't know. I could think of myself as a "purist", but I didn't even touch 
Smalltalk. I know nothing about it, except a few excerpts of code I didn't 
fully understand, the concept that everything is an object including the code 
itself. I did ran a few test programs with an old GNU Smalltalk distribution, 
but that's all, didn't look in them. So no, for me it's not because it isn't 
part of Smalltalk. I think of it as the GOTO of object-oriented programming 
and makes me puke just like the original GOTO... ;-)
 JC> I have mixed feelings about that, but in the end, I'm not sure
 JC> it's particularly bad.  It discourages the use of MI, which is
 JC> usually good. OTOH, some people are certain that all parts of a
 JC> system should be documented and open to use, and they'll
 JC> undoubtedly find this situation quite distasteful.
I remember seeing a framework for a particular version of Object Pascal that 
supported multiple inheritance... It actually *relied* on it and positively 
was the most illogic and barfulous piece of design I ever saw in a 
distributed library. I like to remember this as my first contact with 
"spaghetti objects"... ;-))
Pierre
... There are two major products to come out of Berkeley: Unix and LSD.
--- FMail/Win32 1.20
---------------