Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: Co-ordinating the polymorphism in C++ Message-ID: <27C30630.523F@tct.uucp> Date: 20 Feb 91 23:28:48 GMT References: <1991Feb16.114422.14266@gpu.utcs.utoronto.ca> <27BFE464.3FB9@tct.uucp> <1991Feb19.065741.9669@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 40 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 , "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)