Newsgroups: comp.lang.c++ Path: utzoo!utgpu!craig From: craig@gpu.utcs.utoronto.ca (Craig Hubley) Subject: Re: Co-ordinating the polymorphism in C++ Message-ID: <1991Feb13.011731.10114@gpu.utcs.utoronto.ca> Organization: UTCS Public Access References: <1991Feb11.003849.27340@gpu.utcs.utoronto.ca> <600@taumet.com> Date: Wed, 13 Feb 1991 01:17:31 GMT >craig writes: >|Now that C++ has three polymorphism mechanisms >| - overloading (compile-time) >| - templates (link-time) >| - virtual functions (run-time) > >Overloading need have no relation to polymorphism. Overloading *is* a form of polymorphism, albeit a static one. I can write three functions that accept three different kinds of argument, and tell the user it is one function accepting any of the three. In fact, that is exactly what I *should* tell the user. The fact that this can be reconciled at compile-time, and could in theory be looked up by the programmer who could in theory "know" the exact function called is irrelevant. The fact that this does not require the creation of a run-time table is just an optimization. This is no different that building three types that inherit the same virtual function. So far as the user who simply uses the type is concerned, these approaches are identical. The difference comes when you try to extend the type family. But in both cases, you will write a new function to deal with a new case. If what you are trying to say is that you can overload without using virtuals, that's true. If you're trying to say that a user of a type family needs to think of them as different things, I disagree. In fact it is pretty common to provide the same kind of functions through overloading and virtuals. Imagine an exponent function for ints, vs. one for complex numbers, vs. one for rationals. The user-defined types may be part of a matrix of number types, while the C-like types are not. Two mechanisms, one result. One could make a similar point about friend vs. member functions, but that is only a data hiding issue. It doesn't much affect external behavior. >Templates and polymorphism are orthogonal concepts. Templates are closely related to inheritance in that they are both ways to create a family of types with similar behavior. In fact, templates produce a family of types with *identical* behavior but a slightly different implementation and compatibility with a different set of types (e.g. a list of people vs. a list of shapes). "Orthogonal" in the sense that they can be implemented separately, but not in terms of how they interact to the user. Imagine I create a template "list", and I create a list of "employee". Now I create a list of "manager". If "manager" is a subclass of "employee", should "list of manager" be a subclass of "list of employee" ? There would be few problems in using a list of pointers to managers where a list of pointers to employees was expected. Could the lists have some other relationship? Polymorphism can be defined many ways: from the compiler's point of view, viewing every substitution of one hunk of bits for another as if it might require a compatibility check or a conversion. from the *producing* programmer's point of view, viewing these substitutions in terms of the different mechanisms that need to be invoked to make this work, or from the *consuming* programmers' point of view, in terms of the consistency of behavior of the types and operations in a library or application. What I am suggesting, is that C++ may need some mechanism that makes it easier to look at things from the consuming programmer's point of view. Otherwise, C++ will be a language of code "producers" like C rather than any kind of revolution in programming. The ideas for assertions that have been raised in the group are one idea. These can serve as partial contracts of behavior, and some might be shared by many operations that implement their "consistent" behavior in different ways. Or perhaps such assertions are better left for CASE tools to provide. That's why I'm raising the question. >Steve Clamage, TauMetric Corp, steve@taumet.com 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 28 First Avenue, Toronto, Ontario M4M 1W8 Canada Voice: (416) 466-4097 -- 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