🚀 go-pugleaf

According to craig@gpu.utcs.utoronto.ca (Craig Hubley):
>I want the compiler to override the base class's function wherever
>a derived function is defined that
>	- accepts a parameter list convertible to one the base would accept
>	- returns a value of a type convertible to one returned by base
>my definition of "convertible" is quite restrictive here:  pointers to 
>derived classes, which are legal substitutes for pointers to bases.
>
>Perhaps a different keyword than "virtual" for this type of override, or
>a qualifier to virtual (virtual++ ?  only kidding, maybe virtual* although
>the * is overloaded enough).

I didn't even think of the "virtual*" kind of language addition.
In that context, I could go for it.

>But there are constructs in K&R C that go boom in ANSI C, too.

Granted.  Try, catch and throw will make my programs go boom until I
change my variable names.

>>Code that has already been written depends on all definitions of a
>>given virtual function being identical.  
>
>But it is not "identical" in a semantic sense anyway.

What the captain meant to say was, "... being identically typed."

>Forcing thousands of programmers doing prototypes in other OOPLs to
>bugger everything around to fit C++'s unique and (from what I can see)
>less-powerful resolution of virtuals is a far larger ongoing expense to
>the software industry than a flag or extra keyword.

This statement belies an assumption that all OOPLs are, or should be,
semantically equivalent.  It ain't so, nor should it be: an approach
(OOP) does not a language make.  Smalltalk is a great environment, but
it's lousy for prototyping C++ programs.
-- 
Chip Salzenberg at Teltronics/TCT      <chip@tct.uucp>, <uunet!pdn!tct!chip>
"It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber
   (with reference to the upage bug in Interactive UNIX and Everex ESIX)