Newsgroups: comp.std.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: Co-ordinating the polymorphism in C++
Message-ID: <1991Feb19.065741.9669@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associatess
References: <600@taumet.com> <DSOUZA.91Feb14151948@optima.cad.mcc.com> <1991Feb16.114422.14266@gpu.utcs.utoronto.ca> <27BFE464.3FB9@tct.uucp>
Date: Tue, 19 Feb 1991 06:57:41 GMT

In article <27BFE464.3FB9@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>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.
>
>In the abstract, I like this idea.

You're not the only one.  :)  In fact, if you consider that almost all OO
programming languages only let programmers deal with names/pointers/
references rather than "real" objects, and often treat "derived" types
as exact substitutes for "base" types, they have all already *implemented*
this idea.  Clearly, it doesn't present any insurmountable technical 
problems.  Which leaves the backward-compatibility problems:

>On the other hand, the fact that this rule has not existed in the
>language to date means that currently unrelated functions, which are
>separated perhaps by several layers of derivation, would suddenly
>become alternative implementations of the same virtual function.

It would be quite easy for tools like the eventual Clint to find this 
situation and warn about it, but the fact that it would break existing
code means that a more gradual approach need be adopted.  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).  Or even a compiler flag, which works in 
ANSI C for distinguishing old style definitions which would otherwise
be illegal.

>Also, member functions that are separately legal would suddenly
>conflict with each other if they were both valid overrides for a
>virtual function in a base class.

Same answer as above.  It should be easy to find such situations,
after all the compiler *has to* find them to build the override table.
Who needs Clint ?

>If C++ were still being designed, or were still in use only internally
>to AT&T, this change might have a chance.  But I think it's too late.

Perhaps.  But there are constructs in K&R C that go boom in ANSI C, too.
And one hell of a lot of people used K&R C.

>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.  Outputting "doctor"
rather than "nurse" is a different operation with different effects, 
even if the program can't see what they are.  And I don't believe that
very many people are overloading virtual functions anyway at the moment.
Because the rules are a mess, which was my original point.

One is reminded of the story about "make" where its designer decided not
to change its horrid syntax the DAY AFTER he gave it to TEN other people.
I mean, there is backwards compatibility, and then there is absurdity.

ANSI is supposed to represent the economic interests of the industry as a
whole.  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.  After all, when the words
"catch" and "template" were added as keywords it caused some code (probably
not much) which used these as variable names to break.  This was OK since
that was easy to spot and change.  This kind of problem is easy to spot and
change too:  a parser can flag every instance that would be different under
the old and new rules.  And my guess is, there won't be many.

>For the ANSI committee to
>change this significant aspect of the language would be irresponsible.

Only if they do it without providing a clear migration path wherein it is
possible to avoid code breaking.  I like the alternate or modified keyword
approach.  Then programmers themselves could choose which of the two means
of resolution they found most useful.  My expectation would be that
any programmer prototyping systems in another OOPL, or those that had
been taught the OO paradigm, or learned another OOPL first, like myself,
would prefer the more-liberal overriding paradigm.

>Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>


-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
