Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: Dynamic type loss considered harmless Message-ID: <27D2761F.2F8B@tct.uucp> Date: 4 Mar 91 16:30:23 GMT References: <1991Feb25.201923.14554@gpu.utcs.utoronto.ca> <27CD13B1.649B@tct.uucp> <1991Mar3.005515.18159@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 81 According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27CD13B1.649B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Adding dynamic type information would entail significant changes to >>the meaning of "type". Under current rules, a |Base| that is part of >>a |Derived| is indistinguishable from a plain |Base|. > >In behavior terms, the distinction is already there. I stand corrected. >>attitude that the feature is almost indepensible. IMHO, it's not. > >Every other object-oriented language has it, so burden of proof is on you. Ha! My statement is, "ClassID is not necessary _for_C++_." That languages X, Y and Z have it is irrelevant. They aren't C++. >>>As it stands, you cannot add any type- and context-specific functionality >>>to an object without access to its source code. This greatly restricts >>>reusability, to a level between that of say, Eiffel, and that of Ada. >> >>"Well, don't do that, then." If I can't modify the source code to a >>class, I may use use it, but I usually won't derive from it. > >Then you will never extend anyone else's code, use a framework, etc. I will extend someone else's code -- _if_ I have source, and if I have permission to change it as necessary. In my estimation, attempts to extend C++ code without the authority to make changes -- especially if such extensions depend on what_type_are_you() tests -- will result in "an ill-assorted collection of poorly matching parts, forming a distressing whole": a kludge. >It seems we have found the source of our disagreement. Perhaps we have. >You want a "better C". We want a "reusable library language". Given that we are using C++, we _all_ -- yes, you too -- want a "better C". The question is, which improvements are good and which aren't. I think ClassID is marginal at best. >I suggest that if we can get what we want without imposing any overhead on >you (in fact removing some), you should stop arguing with us. :) The language feature has merit, as I mentioned before, and I don't oppose its introduction pe se. My objection is not to the feature, but to the undeserved praises being heaped upon it, and to the bad code that could result from its unrestrained use. >>IMHO, any attempt to distribute binary-only C++ components intended >>for use _as_base_classes_ is probably doomed to failure ... > >If true, I would suggest that C++ itself is probably doomed to failure >too. "I don't know what language we'll be using in ten years, but it will be called C++." You should know by now that technical issues have seldom stopped languages from becoming mind-numbingly popular. C++ has too much momentum to be stopped now. >>Adding a type tag won't solve the problems of non-virtual >>member functions and private (as opposed to protected) members. > >Why are private members a problem ? They are a problem in the same way that non-virtual member functions are a problem: they are opportunities for the class creator to guess wrong about future re-use patterns. Neither good nor bad programmers can see the future. "Give me source code or give me a pink slip." >I would think you are in a minority in not wanting C++ to support binary >components. It's not that I don't _want_ C++ to support binary components. I do. I also want it to eliminate hunger. I don't believe it can do either. -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre