craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/11/91)
Now that C++ has three polymorphism mechanisms
- overloading (compile-time)
- templates (link-time)
- virtual functions (run-time)
Is anyone thinking about how to reconcile them ? As it stands now, I can
use overloading to add extra arguments to functions, etc., but I can't do
it in my derived classes because virtuals can't be overloaded, etc.
It seems to me that each of these three mechanisms have grown up in an
implementation-driven environment. The user cares only about having
types/classes/whatever you care to call 'em that act predictably. The
programmer cares only about minimizing the work required to create something
new. But it seems as if all this has been designed to minimize the work of
the compiler writer, something which failed miserably in C. As it's often
said, it's "easy to write a mediocre C compiler, very hard to write a good
one".
To propose one small change, if virtuals could be overloaded in type-
compatible ways (i.e. redefining acceptable rguments as pointers to base
classes in place of pointers to base classes, returning pointers to derived
classes in place of pointers to base classes, and permitting extended
argument lists where defaults have been provided) this would add no more
work to the compiler than a simple decision to exhaust matching on virtual
functions before trying for an exact match at a different level, and no
overhead at all to user programs that did not use these features.
In effect it is no more than removing some arbitrary constraints on typing
that are inconsistent with the rules in the rest of C++, which is exactly
the kind of change we have been seeing between versions of C++.
I had a longer post on how/why this is so, with examples, but a crash seems
to have eaten it, so I'll elaborate later if this generates some interest.
--
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!craigsteve@taumet.com (Stephen Clamage) (02/12/91)
craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: |Now that C++ has three polymorphism mechanisms | - overloading (compile-time) | - templates (link-time) | - virtual functions (run-time) |Is anyone thinking about how to reconcile them ? As it stands now, I can |use overloading to add extra arguments to functions, etc., but I can't do |it in my derived classes because virtuals can't be overloaded, etc. Overloading need have no relation to polymorphism. Templates and polymorphism are orthogonal concepts. Virtual function may be overloaded. That would seem to "reconcile" the features quite nicely. -- Steve Clamage, TauMetric Corp, steve@taumet.com
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/13/91)
>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
chip@tct.uucp (Chip Salzenberg) (02/13/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >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. Good. If I wanted a revolution, I'd move to Lithuania. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/14/91)
In article <27B94CC2.5A6C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Good. If I wanted a revolution, I'd move to Lithuania. Not to be a killjoy, but that isn't all that funny. People are dying there. What you want is irrelevant. If building reusable software components is more economically sustainable than building custom parts every time you build an application, you will soon be out of a job (see Cox in Nov/90 IEEE software, and don't accuse me of pushing Objective-C). Neither gunmakers nor cotton processors nor anyone else who had mastered a "craft" made the adjustment to "industry" - they were simply replaced by others who had mastered a more predictable and reproducible process for building parts. I am only suggesting that building these parts is easier if there is a way to explicitly control the behavior presented to the (re)user of a component. C++ could probably incorporate behavior guarantees without much effort and with no runtime overhead. Optimizing compilers have come a long way. So far nobody has disputed this point or shown how it must compromise machine efficiency. Were you against templates, too? 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
dsouza@optima.cad.mcc.com (Desmond Dsouza) (02/15/91)
In article <600@taumet.com> steve@taumet.com (Stephen Clamage) writes: craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: |Now that C++ has three polymorphism mechanisms | - overloading (compile-time) | - templates (link-time) | - virtual functions (run-time) |Is anyone thinking about how to reconcile them ? As it stands now, I can |use overloading to add extra arguments to functions, etc., but I can't do |it in my derived classes because virtuals can't be overloaded, etc. Overloading need have no relation to polymorphism. Templates and polymorphism are orthogonal concepts. Virtual function may be overloaded. The rules for overloading resolution with class derivation is remarkably similar to the virtual function mechanism (in fact, it resembles 'multi-methods' with dispatch based on the derivation closeness of *all* arguments, instead of just the 'this' pointer), except the work is done at compile-time. Templates are the C++ implementation of what Cardelli called 'parametric polymorphism'. You could say templates and class derivation/virtuals are orthogonal, except that template-instantiated classes could have meaningful class-derivation relationships between them. e.g. read-only-list<cars> Vs read-only-list<sports-cars> Virtual functions may NOT be overloaded in the manner Craig seems to want. A derived class,D, with a virtual functions D::f whose arguments differ from those of its base class,B, HIDES the base class function, and does not override B::f. Doing otherwise breaks type-safety. See ARM p.211 for an example. craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >To propose one small change, if virtuals could be overloaded in type- >compatible ways (i.e. redefining acceptable rguments as pointers to base >classes in place of pointers to base classes, returning pointers to derived >classes in place of pointers to base classes, and permitting extended >argument lists where defaults have been provided) this would add no more >work to the compiler than a simple decision to exhaust matching on virtual >functions before trying for an exact match at a different level, and no >overhead at all to user programs that did not use these features. > >In effect it is no more than removing some arbitrary constraints on typing ^^^^^^^^^ >that are inconsistent with the rules in the rest of C++, which is exactly >the kind of change we have been seeing between versions of C++. > 'Arbitrary' ? Thats kinda strong! Sometimes inconvenient, yes. 1 Redefining acceptable arguments to be pointers to derived classes (I'm assuming thats what you meant) instead of to base classes will break strong typing. 2 Returning pointers to derived classes in place of pointers to base classes requires a change to function call/return sequences, particularly if the implementation follows the cfront model of laying out multiply-inherited classes and virtual tables. It can, however, be done without compromising type safety. 3 Extended argument lists in the derived class would definitely change the function call sequence, since optional arguments are currently completely resolved at compile time. Note that you *can* have these three together: a. B::f(B*) b. D::f(B*) c. D::f(D*) But b) overrides a), while c) does not override a). 1 --> really boils down to the "contravariant Vs covariant" controversy. The contravariant rule, which guarantees strong typing, does NOT allow D::f(D*) to override B::f(B*). The covariant rule allows it, but can fail at run-time in some circumstances. I think some of these limitations can be avoided if the compiler is allowed to generate 'customized' code, like the Self compiler does. e.g. 2 versions of D::f() -- one to be called from a B* object, the other from a D* object (or multiple entry points) and emit some run-time type checks and type conversions in the B* version. but thats a pretty major change :-) Desmond D'Souza. -- ------------------------------------------------------------------------------- Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza
chip@tct.uucp (Chip Salzenberg) (02/16/91)
[ This article is almost appropriate for comp.object. Please redirect followups appropriately, according to their content. ] According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27B94CC2.5A6C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Good. If I wanted a revolution, I'd move to Lithuania. > >Not to be a killjoy, but that isn't all that funny. People are dying there. Sigh. I know all about Lithuania's deathly serious struggle for independence. Here's some free advice: Enjoy humor where you find it, even if you find it in war. Living with a frown doesn't help anyone. My point is only that tired old observation that ideology is a hindrance to intelligent choice. If I wanted a "revolution," I wouldn't be programming. Technical fields can do without Lenins and Castros. C++ is very much a pragmatic language, not an ideological one. For example, the language is extensible, but not mutable: you cannot redefine operations that already have a meaning in the base language. Why? Doesn't that reduce the conceptual purity of the type space? Sure. Who cares? Not me. In a related vein, C++ is almost entirely compatible with C. Why? Is C is a particularly good basis on which to build the pure essence of object orientation? Of course not. But with the huge number of C programs and C programmers in existence, it was the natural choice for a language that aims to enhance existing software development efforts without the necessity of starting over. The moral of these examples is that sloganeering will get you nowhere. The market has voted with its feet: Pragmatism wins the day. Point out concrete benefits of specific proposals, and people will take you seriously. Natter about revolutions, and they won't. >What you want is irrelevant. If building reusable software components is >more economically sustainable than building custom parts every time you >build an application, you will soon be out of a job ... That statement is only true if (1) there exists a method of combining pre-made software components into complete applications without programming, (2) that method works significantly better than whatever I'm doing at that future time, (3) my competition is using it, and (4) I'm not willing to change. *IF* (1), (2) and (3) are satisfied, you can bet that (4) won't be. >Neither gunmakers nor cotton processors nor anyone else who had mastered >a "craft" made the adjustment to "industry" - they were simply replaced >by others who had mastered a more predictable and reproducible process >for building parts. That's fine as a history lesson. I'm under no delusions that the way I work is the perfect method of software construction. But misapplied history as as bad as forgotten history. And I have yet to see any evidence whatsoever that the craft of programming is endangered by the spectre of component assembly. I'll believe it when I see it, but I don't see it. (Somebody has to write the modules, after all!) Please remember that I am fond of writing reusable code, simply as a way to avoid unnecessary work. Otherwise, I wouldn't have made the effort to switch myself and my co-workers from C to C++. But agglomeration of modules as described by Objective-C zealots is not the be-all and end-all of programming techniques. It's just another technique, to be used or ignored according to the good judgement of the experienced craftsman. >I am only suggesting that building these parts is easier if there is a way >to explicitly control the behavior presented to the (re)user of a component. A vague statement such as that is impossible to disagree with. It's the talk of "revolutions" that gets my goat. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/16/91)
Since there was a recent post about this very issue in comp.std.c++, since it's a question about the desirability of changing something in the language, and a stream was already going on this subject here, I have cross-posted this and directed followups to comp.std.c++, which I believe is the appropriate forum for such discussions. In article <DSOUZA.91Feb14151948@optima.cad.mcc.com> dsouza@optima.cad.mcc.com (Desmond Dsouza) writes: > >In article <600@taumet.com> steve@taumet.com (Stephen Clamage) writes: > > craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: > > |Now that C++ has three polymorphism mechanisms > | - overloading (compile-time) > | - templates (link-time) > | - virtual functions (run-time) > > |Is anyone thinking about how to reconcile them ? As it stands now, I can > |use overloading to add extra arguments to functions, etc., but I can't do > |it in my derived classes because virtuals can't be overloaded, etc. I stated this badly. They can't be overloaded in the way I want, that is, to allow pointers to derived classes as return values in place of pointers to bases, and pointers to base classes as arguments in place of pointers to derived, and have such an overload override the original function. That is, 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. I am interested in discussing expanding this definition to include other builtin conversions, but I do not think it should extend to user-defined ones. For one thing, the overriding rules should NOT depend on user-defined code, which can change and cause unexpected chaos. But the builtin conversions will not change in this fashion, and are largely there to ease the pains of dealing with the C data types, and to manage inheritance. Other OO languages permit such type-compatible overloading, and in some languages (e.g. Trellis) it is enforced. That is, you can only define changes that will leave a derived type a legal substitute for a base type in all circumstances (i.e. type-safe). > Overloading need have no relation to polymorphism. > Templates and polymorphism are orthogonal concepts. > Virtual function may be overloaded. > >The rules for overloading resolution with class derivation is >remarkably similar to the virtual function mechanism (in fact, it >resembles 'multi-methods' with dispatch based on the derivation >closeness of *all* arguments, instead of just the 'this' pointer), >except the work is done at compile-time. I suppose I am suggesting they ought to be one mechanism, not two. Overloaded functions should also be permitted to return "more specialized" types and accept "more general" arguments. >Templates are the C++ implementation of what Cardelli called >'parametric polymorphism'. You could say templates and class >derivation/virtuals are orthogonal, except that template-instantiated >classes could have meaningful class-derivation relationships between >them. e.g. read-only-list<cars> Vs read-only-list<sports-cars> Thanks for the reference. To invoke Trellis again, its type-generators (equivalent to templates) can be declared "not_flat" which simply means that the generated types (e.g. collections) have the same inheritance relationship as the type used to generate them. >Virtual functions may NOT be overloaded in the manner Craig seems to want. Not at present, although I think a strong case can be made for the change. >A derived class,D, with a virtual functions D::f whose arguments >differ from those of its base class,B, HIDES the base class function, >and does not override B::f. Doing otherwise breaks type-safety. See This is a rather narrow notion of type-safety. I would argue that the general theory does not apply here. C++ recognizes distinct types but also blurs the distinction between some types (e.g. pointers to base vs. derived, numerical types) with its unique builtin type conversion. This causes some things of "different" type to be guaranteed to be treated as if they were the same, so long as not more than one user-defined conversion is invoked, and I am suggesting we leave them out of this completely. In this case, the argument list may well be convertible to one that B::f will accept, and with only builtin conversions being invoked. There is no change to any user program that will cause this conversion to be invalid, thus this argument list is always a valid substitute for that of B::f. > craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: > > >To propose one small change, if virtuals could be overloaded in type- > >compatible ways (i.e. redefining acceptable rguments as pointers to base > >classes in place of pointers to base classes, returning pointers to derived > >classes in place of pointers to base classes, and permitting extended > >argument lists where defaults have been provided) this would add no more > >work to the compiler than a simple decision to exhaust matching on virtual > >functions before trying for an exact match at a different level, and no > >overhead at all to user programs that did not use these features. > >In effect it is no more than removing some arbitrary constraints on typing > ^^^^^^^^^ > >that are inconsistent with the rules in the rest of C++, which is exactly > >the kind of change we have been seeing between versions of C++. > >'Arbitrary' ? Thats kinda strong! Sometimes inconvenient, yes. I will stick to my gadfly term. Every other language that pretends to be OO at least permits, usually encourages and sometimes enforces what I propose. It arises from sound principles, and C++ is arbitrary in flouting them without a clear reason that is stated in practical terms, not with abstract terms like "type safety" which I have demonstrated mean something different in C++ than in other languages. Second, C++ itself permits data values of these types to be freely substituted but somehow flinches at permitting functions that return these types from being similarly substituted (i.e. overloaded functions can't return the more specialized type). Thus it is inconsistent with itself. >1 Redefining acceptable arguments to be pointers to derived classes > (I'm assuming thats what you meant) instead of to base classes will > break strong typing. No, the opposite. You can *generalize* arguments but not *specialize* them without risking failures. The derived virtual may try to use aspects of the derived type it expects, when only the base type is there, since that was what the original base virtual expected, and that was what programmers provided. That would be equivalent to automatically casting B* to D*... which C++ doesn't do. If the base class has a virtual thus: class B { virtual B* foo(D*); } Then this is what we are talking about (comment from a previous post) class D : public B { // D* is always demotable to B*, so the function call B* foo(B*) {}; // D::foo(D*) should be equivalent to D::foo((B*)D*) // It could also be interpreted as B::foo(D*), which // might be why it's illegal, but a simple rule to // exhaust argument matching on virtuals before trying // the base functions (if they are tried at all) would // resolve this ambiguity. } And this is what we were talking about above: class E : public B { D* foo(B*) {}; // Similarly, any context that ends up calling // D::foo() where B::foo() is expected will // receive a D* value that can be used as a B*. // But C++ says that overloads and virtuals // can't change the return type at all. Why not // allow it where the objects are the same size // and C++ already has a built-in promotion ? } You are "doing the same" (D) or "doing more" (E) with "less information". And here are the consequences: // if all of the above were allowed, extending C++ consistently with the // rules mentioned above yields the following results: // main { B* b; D* d; E* e; b->foo(b); // illegal, fine, B* shouldn't automatically promote b->foo(d); // legal, exact match, return B* d->foo(b); // legal, exact match, return B* d->foo(d); // legal, D::foo((B*)d), return B*, ignore B::foo(D*) e->foo(b); // legal, exact match, return D* e->foo(d); // legal, E::foo((B*)d), return D*, ignore B:foo(D*) } Whether there are any other consequences, is up to us to determine. :) >2 Returning pointers to derived classes in place of pointers to base > classes requires a change to function call/return sequences, > particularly if the implementation follows the cfront model of > laying out multiply-inherited classes and virtual tables. It can, > however, be done without compromising type safety. Agreed. I didn't expect it would be a picnic for compiler writers. It is people using and writing code I am thinking about. There was an excellent post in comp.std.c++ showing the kind of problems that are created by NOT having this mechanism. >3 Extended argument lists in the derived class would definitely change > the function call sequence, since optional arguments are currently > completely resolved at compile time. We haven't really talked about the implications of allowing extended lists. One issue with such a change would be that calls to virtual functions using the extended arguments are incompatible with the original base function. Perhaps the compiler should reject any such call where the base (with the shorter argument list) is one of the object's potential types. In other words, it's only legal where I declare, say, a D* or pointer to a type derived from D, but not where I declare a B*. It would be nice to have a way to test the actual type, and do type-specific things in the case arm where the type is guaranteed to match, but C++ doesn't allow programmers to see the darn type tag at all. >Note that you *can* have these three together: >a. B::f(B*) >b. D::f(B*) >c. D::f(D*) > >But b) overrides a), while c) does not override a). Yes. This is fine. But my point is given: d. B* B::f(D*) e. B* D::f(D*) f. D* D::f(D*) g. D* D::f(B*) h. B* D::f(B*) e) overrides d) f) should be allowed and overrides d) (compile error if e) already exists) g) should be allowed and overrides d) (compile error if e) or f) exists) h) for completeness, should be allowed, overrides d), unless e)-g) exist) Calls to d) plus the builtin conversion would invoke f)-h) correctly. Values returned by f) and g) are converted by builtins to those acceptable by any context originally calling d). >1 --> really boils down to the > "contravariant Vs covariant" >controversy. The contravariant rule, which guarantees strong typing, >does NOT allow D::f(D*) to override B::f(B*). The covariant rule >allows it, but can fail at run-time in some circumstances. This isn't what I'm proposing, as I make clear above. I'm against runtime failure in C++, and as stated above I don't think the general principles of strong typing can be applied to C++ unless one deals explicitly with the builtin conversions. >I think some of these limitations can be avoided if the compiler is >allowed to generate 'customized' code, like the Self compiler does. >e.g. 2 versions of D::f() -- one to be called from a B* object, the >other from a D* object (or multiple entry points) and emit some >run-time type checks and type conversions in the B* version. This is a possibility, I see no reason for C++'s compiler to always default towards braindeath, and it satisifies the rule that it costs nothing if you don't ever try to use this feature. But as Bjarne said, this would "bless contravariance". >but thats a pretty major change :-) I agree. I don't see much reason for it. C++ is designed to let you do this sort of thing for yourself, to some degree, although testable type tags are certainly required to do it right. You just gotta SEE the type of the object sometimes. >Desmond D'Souza. > > Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324 > Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza -- 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
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/16/91)
In article <27BC17C4.6304@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >[ This article is almost appropriate for comp.object. Please redirect > followups appropriately, according to their content. ] Followups to comp.sw.components. The C++ issues are now in another thread with followups to comp.std.c++, where the issue of "fixing" the types returned/accepted by virtuals was raised by someone else. Since it involves changing the language it belongs in .std rather than .lang Since this one is about the relationship of C++ to the so-called "software component industry" I've left it here. >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>In article <27B94CC2.5A6C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>>Good. If I wanted a revolution, I'd move to Lithuania. >> >>Not to be a killjoy, but that isn't all that funny. People are dying there. > >Sigh. I know all about Lithuania's deathly serious struggle for >independence. Here's some free advice: Enjoy humor where you find it, >even if you find it in war. Living with a frown doesn't help anyone. I got the joke. I suppose I was rather annoyed that you had read the entire post and then decided to comment only on this rather emotive conclusion. What I guess I should have said was "if we want to get reusable components with predictable behavior out of C++, we better start thinking about this." with the implication that extending C alone is not likely to permit such components to be easily developed. >My point is only that tired old observation that ideology is a >hindrance to intelligent choice. If I wanted a "revolution," I >wouldn't be programming. Technical fields can do without Lenins >and Castros. But not without Stroustrops and Coxes and Kays. Leadership of a different sort, I'll grant. No need to natter over these terms anymore. I'll refrain from calling it a revolution, if you like. >C++ is very much a pragmatic language, not an ideological one. Hmm... but in failing to do anything drastic you may fail to do anything at all. Politicians pride themselves on being "pragmatic" rather than "ideological" or "partisan" too. Is C++ a politician's language ? :) For those who can't argue well enough for OO to get to ues a real OO language. :) :) >For example, the language is extensible, but not mutable: you cannot >redefine operations that already have a meaning in the base language. >Why? Doesn't that reduce the conceptual purity of the type space? >Sure. Who cares? Not me. Me neither. I don't expect conceptual purity out of a C extension. >In a related vein, C++ is almost entirely compatible with C. Why? Is >C is a particularly good basis on which to build the pure essence of >object orientation? Of course not. But with the huge number of C >programs and C programmers in existence, it was the natural choice for >a language that aims to enhance existing software development efforts >without the necessity of starting over. Yes, a reasonable design choice. Training is most of the costs of introducing any new software, and development tools are the most labor-eating software of all... next to word processors and spreadsheets. And those aren't likely to change that much either in the next 20 years. However, none of what I am suggesting would change any part of C++ that was inherited from C. So this is not an issue. And these changes would not even affect present C++ programmers or their code. >The moral of these examples is that sloganeering will get you nowhere. I was not "sloganeering". I said a lot of other things and ended with what you chose to take as a slogan. That's enough about that, from me anyway. >The market has voted with its feet: Pragmatism wins the day. Point >out concrete benefits of specific proposals, and people will take you >seriously. This is being done in comp.std.c++. Someone else proposed one of the very same changes as I did, just today. They posted their code and why the existing rules made it a mess. I couldn't do that because all of my code that does this is in other languages. I am a pragmatic guy, and previously I hadn't tried to get C++ to do these things. >>What you want is irrelevant. If building reusable software components is >>more economically sustainable than building custom parts every time you >>build an application, you will soon be out of a job ... > >That statement is only true if (1) there exists a method of combining >pre-made software components into complete applications without >programming, This "method" could require some programming and still beat the cost/ benefit beejeezus out of anything built mostly from scratch. Anyway, (1) is already coming - check out NewWave, or the OMG. If what you mean is that users will always need programmers, I'll buy that. >(2) that method works significantly better than whatever >I'm doing at that future time, > >(3) my competition is using it, and >(4) I'm not willing to change. > >*IF* (1), (2) and (3) are satisfied, you can bet that (4) won't be. Fair enough. You've got plenty of time to change your mind, improve your tools, or whatever. If it's necessary, and there's a chance that it won't be. >>Neither gunmakers nor cotton processors nor anyone else who had mastered >>a "craft" made the adjustment to "industry" - they were simply replaced >>by others who had mastered a more predictable and reproducible process >>for building parts. > >That's fine as a history lesson. I'm under no delusions that the way >I work is the perfect method of software construction. But misapplied >history as as bad as forgotten history. And I have yet to see any >evidence whatsoever that the craft of programming is endangered by the >spectre of component assembly. I'll believe it when I see it, but I >don't see it. (Somebody has to write the modules, after all!) The craft of programming will continue to exist, but it will migrate, hopefully, into higher-level concerns and lowest-level details. Architects and general contractors still exist side-by-side, as do plumbers. The analogies to buildings or guns or cotton aren't mine, they come from others, notably Cox, so I refer you there to determine if you think they are misapplied. >Please remember that I am fond of writing reusable code, simply as a >way to avoid unnecessary work. Otherwise, I wouldn't have made the >effort to switch myself and my co-workers from C to C++. But "The reasonable man accepts things as they are - thus all progress depends on the unreasonable man" (paraphrase) - G. Bernard Shaw My version, and probably yours too from what you say: "The industrious man is always willing to work to overcome deficiency - thus all breakthroughs depend on the lazy man" :) >agglomeration of modules as described by Objective-C zealots is not >the be-all and end-all of programming techniques. It's just another >technique, to be used or ignored according to the good judgement of >the experienced craftsman. Well, this bears an uncanny resemblance to what those gunmakers said. Sure, there are drawbacks to standardized components, like over-generality and the need to trust other programmers. But if I can build software that does 95% of what I need at 10% of the cost, I am pretty likely to figure out good reasons not to need that 5%. Like nice designs etched on the gunstock, or even a certain level of accuracy. Mass-produced cars and guns were markedly inferior to their handmade counterparts in the beginning. They appealed to people because they were *cheap*. Period. Only once a huge market groundswell had gathered was there enough R&D money to really improve the quality of the mass-produced product. >>I am only suggesting that building these parts is easier if there is a way >>to explicitly control the behavior presented to the (re)user of a component. > >A vague statement such as that is impossible to disagree with. Then agree, and let's talk about how to do it. Assertions ? Contracts ? Comments ? There have been good posts about all of these lately. >It's the talk of "revolutions" that gets my goat. Clearly. Well, hopefully the analogies get your goat less. If not, ignore 'em and follow up on my other, strictly technical post. In any case, I don't care to argue for the "revolution" any more. That's Brad Cox's job, and he does good work. >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
chip@tct.uucp (Chip Salzenberg) (02/18/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >Overloading *is* a form of polymorphism, albeit a static one. I agree. >This is no different that building three types that inherit the same >virtual function. I disagree. Overloading is a static phenomenon limited to compile time, and that fact is visible to the programmer. For example, given a base class B and a derived class D: extern void foo(B&); extern void foo(D&); D d; B& b = d; foo(b); It is the "foo(B&)" function that will be called, the decision being based on the _static_ type of the argument. Likewise, given a non-virtual member function "foo()" defined in both B and D [no pun intended!]: D d; B& b = d; b.foo(); It is B::foo() that is called, this decision being made in a way very similar to the resolution of overloaded functions. In contrast, virtual function resolution is a _dynamic_ phenomenon. Were foo() made virtual, however, the decision between B::foo() or D::foo() -- or even some other, as yet unimagined, function E::foo() -- would be deferred until run time. So I conclude that it is NON-virtual member function resolution that correspond most closely to function overloading. >>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. The preprocessor is also a means to creating a class family; yet it is obviously unrelated to inheritance per se. As I understand templates, it is true that classes may be defined in template form, but so may anything, including non-member functions that could otherwise be part of an old C program, e.g. a generic qsort() comparison function. So templates and inheritance _are_ truly orthogonal. >"Orthogonal" in the sense that they can be implemented separately, but >not in terms of how they interact to the user. Again, though, templates are a purely static phenomenon. They are utterly unlike virtual functions, which are resolved at run time. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
chip@tct.uucp (Chip Salzenberg) (02/18/91)
Craig writes a very pragmatic [:-)] description of object oriented programming and its possible future directions. I suppose I should have read Craig's original article in its entirety, rather than judging its contents by the one "revolution" remark. Mea culpa. According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >If what you mean is that users will always need programmers, >I'll buy that. I'm glad. :-) Some people have truly unrealistic expectations for the reduction of programming effort. IMHO, given the expanding importance of computers in society, programming tasks will expand to use all available programmers. If OO makes us more productive, that's all the better: we'll get more done. But we'll still be needed. >The craft of programming will continue to exist, but it will migrate, >hopefully, into higher-level concerns and lowest-level details. What he said. >My version, and probably yours too from what you say: >"The industrious man is always willing to work to overcome deficiency - > thus all breakthroughs depend on the lazy man" :) Absolutely. Larry Wall's three virtues of programmers are Laziness, Impatience and Hubris. And let us not forget Heinlein's great example for programmers everywhere: "The Man Who Was Too Lazy To Fail." >Mass-produced cars and guns were markedly inferior to their handmade >counterparts in the beginning. They appealed to people because they >were *cheap*. Period. Indeed (and handmade goods are still superior in quality). But we here at TCT already have a production line: one person with a box of standard streamer tapes, and a "publications department" consisting of a few people and a huge copying machine. So much for software production! Programming is not production in the industrial sense. I would consider it more similar to the design department of the car and gun manufacturers than to their production lines. Programming is a low-volume, high-creativity consolidation of thought into a formal notation. As such, it is fundamentally different from the high-volume, low-creativity work that characterizes mass production. (Don't get hung up on the term "low-volume." As programming methods progress, our sadly limited mental output can produce greater and greater results.) >I am only suggesting that building these parts is easier if there is a way >to explicitly control the behavior presented to the (re)user of a component. I would like to see this done with assertions as part of the C++ class definition. The more checking that can be done by the compiler, the better. But I am not willing to jump on the Objective-C bandwagon, if only because static typing is a useful way to avoid a great deal of run-time messaging and debugging overhead. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz