aed@netcom.COM (Andrew Davidson) (02/14/91)
Here is my problem, I have some processing that only applies for
certain types of objects. If an object is not of the correct type I
want to do some error stuff.
The problem is how do I fiqure out what the type of the object is. I
could return a string, ie provide an istype member function but then the calling function would have to
know what the string is in advance, It also wont work with inheritance
Thanks Andy
--
-----------------------------------------------------------------
"bede-bede-bede Thats all Folks"
Porky Pig
Andy Davidson
Woodside CA.
aed@netcom.COM
-----------------------------------------------------------------bourd@buster.cps.msu.edu (Robert Bourdeau) (02/14/91)
In article <23984@netcom.COM>, aed@netcom.COM (Andrew Davidson) writes: |> Here is my problem, I have some processing that only applies for |> certain types of objects. If an object is not of the correct type I |> want to do some error stuff. |> |> The problem is how do I fiqure out what the type of the object is. I |> could return a string, ie provide an istype member function but then |> the calling function would have to |> know what the string is in advance, It also wont work with inheritance |> |> Thanks Andy Why not do what Borland did in their class library. There is a header file use by the Borland class library called clssname.h or something like that, I can't remember exactly. Anyway, it look something like typedef int classType #define objectClass 0 #define containerClass (objectClass+1) #define collectionClass (containerClass+1) and so on.... The isA() member function for the class Container would loook something like: class Container : Object { .... public: .... classType isA() { return containerClass; } .... }; I am not sure how this is so terribly different from what you are proposing above, except that it is more efficient. Nevertheless, this idea will work with inheritance (if I understand what you are stating your problem to be). --- Robert Bourdeau --- bourd@buster.cps.msu.edu --- Michigan State University
throopw@sheol.UUCP (Wayne Throop) (02/16/91)
> aed@netcom.COM (Andrew Davidson) > I have some processing that only applies for certain types of objects. > If an object is not of the correct type I want to do some error stuff. > The problem is how do I fiqure out what the type of the object is. I don't know the full context of this, but from this fragment it seems that testing the type of an object to decide what to do with it is wrong-headed from the very start from an object oriented perspective. Isn't a large part of the benefit of the OO idea the avoidance of all the "if"ing and "case"ing and "select"ing that goes on when algorithms are divorced from the data they manipulate? So, shouldn't the solution be to simply perform the operation on ALL the objects, and arrange for the ones to which it doesn't apply to treat it as a NOP? And, if necessary, supplying a derived or containing class (or rather, classes) to arrange for this if it isn't reasonable to add these operations to the original class(es)? As I said, I may be missing some context, but that's the way it seems to me. -- Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/19/91)
In article <1190@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: >> aed@netcom.COM (Andrew Davidson) >> I have some processing that only applies for certain types of objects. >> If an object is not of the correct type I want to do some error stuff. >> The problem is how do I fiqure out what the type of the object is. > >I don't know the full context of this, but from this fragment it seems >that testing the type of an object to decide what to do with it is >wrong-headed from the very start from an object oriented perspective. "objectively" one would have an error-handling routine that would do nothing for objects of the correct type, and something else for objects of other types. However, error-handling is typically far more context- dependent, and the main idea of O-O is to keep objects context-free and exclude non-portable, non-reusable details like how to respond to an application-specific problem. That is why most O-O languages (probably all by now) incorporate a separate error-handling mechanism. >Isn't a large part of the benefit of the OO idea the avoidance of all >the "if"ing and "case"ing and "select"ing that goes on when algorithms >are divorced from the data they manipulate? Yes, this is a large part of being context-free, but in cases where the algorithm is application-dependent, you DON'T want parts of it seeping into your objects. As I pointed out, error-handling is one such situation, but imagine a database query: "from the list of shapes, show me all the circles of diameter > 30" Arg. A totally contextual algorithm. I do NOT want to write a special function for all shapes to respond to this. What I would really like to do is something like: "if x.type=circle then if x.diameter > 30 then return x" But without a type tag, I can't even check if there IS a diameter! Arg! So I write my own type tag, incompatible with everyone else's, or risk errors. But in more intelligent O-O languages, asking the type, or better, asking if there is a diameter, is a fundamental operation in type Object that all objects can do. >So, shouldn't the solution be to simply perform the operation on ALL the >objects, and arrange for the ones to which it doesn't apply to treat it >as a NOP? And, if necessary, supplying a derived or containing class (or >rather, classes) to arrange for this if it isn't reasonable to add these >operations to the original class(es)? This was the solution I refuted above. In C++ you can often define free overloaded functions to deal with such contextual cases in an application, and make up for the fact that the predefined classes don't deal with them. But it's a mess, subject to combinatorial explosion and constant rewriting of your classes. And most O-O languages don't do it that way. >As I said, I may be missing some context, but that's the way it seems to me. And to most people, until they recognize some of the limits of having only one simple polymorphism mechanism. C++ has several (overloading, conversion, virtuals, templates) but it doesn't co-ordinate 'em very well. >Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org -- 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
barmar@think.com (Barry Margolin) (02/19/91)
In article <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >Arg. A totally contextual algorithm. I do NOT want to write a special >function for all shapes to respond to this. What I would really like to >do is something like: > "if x.type=circle then if x.diameter > 30 then return x" Even in languages that provide a way to do that, you probably wouldn't want to write it that way, because it doesn't handle derived classes properly. For instance, if square is derived from regular_polygon and quadrilateral, x.type can't be all three. What you want is something like if x.is_circle() ... or if x.is_of_type("circle") ... The latter can be implemented by writing something like int circle::is_of_type(char *type) { return (strcmp(type, "circle") == 0) || shape::is_of_type(type); } int square::is_of_type(char *type) { return (strcmp(type, "square") == 0) || quadrilateral::is_of_type(type) || regular_polygon::is_of_type(type); } -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwu@nujoizey.tcs.com (George Wu) (02/19/91)
In article <23984@netcom.COM>, aed@netcom.COM (Andrew Davidson) writes: |> Here is my problem, I have some processing that only applies for |> certain types of objects. If an object is not of the correct type I |> want to do some error stuff. I have wanted to do this very thing several times, and everytime, I decided my approach was entirely wrong. Anytime you find yourself needing to ask an object it's type, be sure the carefully consider why you need to do so. What you're looking for is not a workaround, but the right way to do things. In most (all?) cases, if some work needs to be done dependant upon the type of an object, that code should be implemented in the classes of those objects. For instance, suppose I wanted to to write something like: switch (object->getType()) { case X: executeForX(); break; case Y: executeForY(); break; // . . . } Instead, I would write this do resemble: class X { void execute(); // . . . }; class Y { void execute(); // . . . }; // . . . object->excute(); where classes X and Y probably inherit a common definition of the execute() method as a virtual function. George ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.
steve@taumet.com (Stephen Clamage) (02/20/91)
craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >imagine a database query: > "from the list of shapes, show me all the circles of diameter > 30" >Arg. A totally contextual algorithm. I do NOT want to write a special >function for all shapes to respond to this. What I would really like to >do is something like: > "if x.type=circle then if x.diameter > 30 then return x" >But without a type tag, I can't even check if there IS a diameter! All you have to do is make a virtual function diameter() for all Shapes. A function which expects to operate on a class of type Shape may reaonably expect all the functionality of Shape to be present. It may not reasonably expect specific behaviors of classes derived from Shape to be present. If checking diameters of a Shape is something you would expect to do, then Shape should have a virtual function diameter(). There would be defined behavior (such as return 0 or throw an exception) for classes which do not have diameters (i.e., a Shape which is not closed). But if from class Shape you derive ClosedShape and OpenShape, and have a diameter only for a ClosedShape, you have no business looking for a diameter on a list of Shapes -- only on a list of ClosedShapes. This is all part of the system design. -- Steve Clamage, TauMetric Corp, steve@taumet.com
sdm@cs.brown.edu (Scott Meyers) (02/20/91)
In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes: | >imagine a database query: | | > "from the list of shapes, show me all the circles of diameter > 30" | | All you have to do is make a virtual function diameter() for all Shapes. | A function which expects to operate on a class of type Shape may | reaonably expect all the functionality of Shape to be present. It may | not reasonably expect specific behaviors of classes derived from Shape | to be present. This is of course the right way to go, and most of the time it is a workable solution, but there are times when it simply won't do. For example, I have a system that builds directed graphs that represent programs, and there are various kinds of arcs in the graph: class Arc { ... }; class ControlArc: public Arc { ... }; class DataArc: public Arc { ... }; class NPControlArc: public ControlArc { ... }; ... For the code that I write (i.e., the code that maintains the graph), I have all the virtual functions defined in the appropriate places, but applications that *use* this graph structure often need to do things that are both specific to the application and specific to the type of the arc. For example, an application might want to draw different kinds of arcs differently on the screen, i.e., control arcs are red and data arcs are black. How can they do this if all they have is a set of Arc pointers? In this case, I could provide a virtual function called draw, but in general an application might want to do something I've never heard of, so there will be no virtual function for them to call. That being the case, there needs to be a way to find out the "real" type of the Arc pointer, so they can do the appropriate thing. I personally believe that we need language support for this kind of thing, but it would be so prone to abuse and Bjarne is so dead-set against it that I don't hold out much hope that it will be seriously considered by the ANSI committee. Instead, I think that compiler vendors will add proprietary support for it, and there will be a market free-for-all. I know that at least one compiler vendor already has implemented such a facility for getting type information at runtime. The bottom line is that virtual functions are wonderful things and can almost always be used to achieve what you want, but there are times when you truly *do* need to get type information as you run. Scott ------------------------------------------------------------------------------- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."
lattanzi@decwrl.dec.com (Len Lattanzi) (02/20/91)
In article <65451@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes: :In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes: :| >imagine a database query: :| :| > "from the list of shapes, show me all the circles of diameter > 30" :| :| All you have to do is make a virtual function diameter() for all Shapes. :| A function which expects to operate on a class of type Shape may :| reaonably expect all the functionality of Shape to be present. It may :| not reasonably expect specific behaviors of classes derived from Shape :| to be present. : :This is of course the right way to go, and most of the time it is a :workable solution, but there are times when it simply won't do. : :I personally believe that we need language support for this kind of thing, :but it would be so prone to abuse and Bjarne is so dead-set against it that :I don't hold out much hope that it will be seriously considered by the ANSI :committee. Instead, I think that compiler vendors will add proprietary :support for it, and there will be a market free-for-all. I know that at :least one compiler vendor already has implemented such a facility for :getting type information at runtime. : :The bottom line is that virtual functions are wonderful things and can :almost always be used to achieve what you want, but there are times when :you truly *do* need to get type information as you run. : :Scott This is especially true for expanding library interfaces. I wished for an "interactive(istream&)" predicate but had my hands tied. I could either compare pointer-to-members to guess at class type (boo! hiss!) or use iostream state variables to record this information. Something like a property-list per object is probably the desire of most lisp hackers. \ Len Lattanzi (Migration Software Systems Ltd 408 452 0527) <len@migration.com>
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/20/91)
In article <1991Feb19.023528.29494@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >>Arg. A totally contextual algorithm. I do NOT want to write a special >>function for all shapes to respond to this. What I would really like to >>do is something like: >> "if x.type=circle then if x.diameter > 30 then return x" > >Even in languages that provide a way to do that, you probably wouldn't want >to write it that way, because it doesn't handle derived classes properly. In languages that support specification inheritance, x.type=circle would be true for all types descended from circle. They would be considered first-class circles. Not so in C++. >For instance, if square is derived from regular_polygon and quadrilateral, >x.type can't be all three. To find the exact physical type of something an alternate name is often used: (e.g. .basetype vs. .Mytype in Trellis). Kind of like oriental family names, where your first (and most important) name is your surname, and if you care to qualify that with your given name you can, and then you are talking about yourself rather than your family. To stick to the hopefully-emerging-standard terminology, x.TYPE *can* be all three (i.e. it answers true to "regular_polygon", "quadrilateral", AND "square") but x.CLASS *can't* be (it is, physically, a "square"). >What you want is something like > > if x.is_circle() ... >or > if x.is_of_type("circle") ... [craig: tag this @] or if x.is_derived_from("circle") ... if that guarantees a diameter. However, in C++ it doesn't, and if you change the class or member name it gets painful. A better way would be to check directly for the presence of a diameter before checking it: if x.has_member("diameter") ... >The latter [craig: @] can be implemented by writing something like > >int circle::is_of_type(char *type) >{ > return (strcmp(type, "circle") == 0) || shape::is_of_type(type); >} Yes, although this is painfully redundant (repeating the name of the class, and all its bases) it will work for the subclasses too. >int square::is_of_type(char *type) >{ > return (strcmp(type, "square") == 0) || > quadrilateral::is_of_type(type) || > regular_polygon::is_of_type(type); >} If you just build a function that lists its base types into every class, you could do this with a template. Similarly, if you build a function that lists all public members, you could implement x.has_member("..."). The problem with all this, of course, is that now we are managing information that the compiler already has, and building many dependencies on base types into our code, although thankfully this avoids dependencies on derived types. >Barry Margolin, Thinking Machines Corp. > >barmar@think.com >{uunet,harvard}!think!barmar -- 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
jbuck@galileo.berkeley.edu (Joe Buck) (02/20/91)
In article <65451@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes: |> The bottom line is that virtual functions are wonderful things and can |> almost always be used to achieve what you want, but there are times when |> you truly *do* need to get type information as you run. Scott then goes on to talk about how the ANSI committee is unlikely to give him what he wants. What do you care what the committee says? If you must have this feature, write, in the baseclass virtual const char* myType() = 0; then do const char* ControlArc::myType() { return "ControlArc";} It is already in the language if you must have it. However, I would still discourage you from this type of programming. Why? Because people will add new types of Arcs and you won't deal with them properly. You're dealing with objects based on an exact match of some type string instead of based on some relevant attribute that a virtual function could return. You're wiring in a list of classes you can handle, requiring more code rewriting as classes are added. But if you really want to do it, you can, so stop saying that C++ won't give you run-time type information. It's trivial to add if you want it. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
jgro@lia (Jeremy Grodberg) (02/20/91)
In article <1991Feb19.023528.29494@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >>Arg. A totally contextual algorithm. I do NOT want to write a special >>function for all shapes to respond to this. What I would really like to >>do is something like: >> "if x.type=circle then if x.diameter > 30 then return x" > >Even in languages that provide a way to do that, you probably wouldn't want >to write it that way, because it doesn't handle derived classes properly. >For instance, if square is derived from regular_polygon and quadrilateral, >x.type can't be all three. What I would like to see is something like Object Pascal's member() function. It takes an object and a type name, and returns true if the object is of that type (or is derived from that type). Of course, member is a bad choice of names for C++, so I'll just call the function "is." So you would write Craig's query: "if (is(x, Circle)) then if x.diameter > 30 then return x" All this information is available at compile time, the problem, as pointed out in the ARM, is agreeing what information to store and how and where to store it. I'm all for it. -- Jeremy Grodberg "I don't feel witty today. Don't bug me." jgro@lia.com
sdm@cs.brown.edu (Scott Meyers) (02/20/91)
In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: | In article <65451@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes: | |> The bottom line is that virtual functions are wonderful things and can | |> almost always be used to achieve what you want, but there are times when | |> you truly *do* need to get type information as you run. | What do you care what the committee says? If you must have this feature, | write, in the baseclass | | virtual const char* myType() = 0; | | const char* ControlArc::myType() { return "ControlArc";} | | It is already in the language if you must have it. However, I would still | discourage you from this type of programming. | | Why? Because people will add new types of Arcs and you won't deal with | them properly. You're dealing with objects based on an exact match of | some type string instead of based on some relevant attribute that a | virtual function could return. You're wiring in a list of classes you | can handle, requiring more code rewriting as classes are added. | | But if you really want to do it, you can, so stop saying that C++ won't | give you run-time type information. It's trivial to add if you want it. The biggest problem with your approach is that for it to function correctly, every class derived from Arc *must* define the virtual function myType, but there is no way to make the compiler ensure this! So if somebody creates a new class and forgets to write the appropriate myType function, they'll inherit the inappropriate myType function, and the compiler will be as happy as can be while the code is wrong wrong wrong. If there were compiler support for getting at runtime type information, this whole maintenance/enhancement nightmare would disappear. And as you yourself point out, you often don't want only an exact type match, you're often interested in whether an object "isa" particular type, which means that it inherits from that type at some point, though perhaps not directly. Using virtual functions it is again possible to set things up so that the general predicate object.isa(typeSpecifier) works correctly, but I wouldn't call it "trivial." Furthermore, all such schemes suffer from the requirement that every class explicitly provide new information, again without any warning from a compiler if they fail to do so. By the way, this problem is very similar to that of providing support for safely casting from a base pointer to a derived pointer provided that the base pointer "really" points to a derived object. To see how "trivial" this is (especially in the case of multiple inheritance), check out how it's done in the NIH library. I read about it in The C++ Report: @ARTICLE{c++-casting, AUTHOR = {Desmond D'Souza}, TITLE = {{Inheritance, Virtual Base Classes, and Casts}}, JOURNAL = c++report, YEAR = {1990}, VOLUME = {2}, NUMBER = {7}, MONTH = {July/August} } Scott ------------------------------------------------------------------------------- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."
chip@tct.uucp (Chip Salzenberg) (02/21/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >But in more intelligent O-O languages, asking the type, or better, >asking if there is a diameter, is a fundamental operation in type >Object that all objects can do. "More intelligent"? Your prejudices are showing. :-) C++ is statically typed. And there is no requirement that all classes be derived from a hypthetical Object class. So the features you desire cannot be accomplished in C++. BTW, I happen to find C++ an excellent tool for _exactly_ those reasons. I pay only for those OOP features I need, and no more. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "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)
dlw@odi.com (Dan Weinreb) (02/21/91)
In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes:
All you have to do is make a virtual function diameter() for all Shapes.
A function which expects to operate on a class of type Shape may
reaonably expect all the functionality of Shape to be present. It may
not reasonably expect specific behaviors of classes derived from Shape
to be present.
In addition to what other people have mentioned, this approach isn't
very good from the point of view of extensibility. Suppose that we
are trying to make an extensible graphics system. We would like a
programmer-extended to be able to add new kinds of shapes, by
subclassing Shape.
Suppose a programmer wants to add Ellipses which has major_axis and
minor_axis function members, and we'd like be able to ask for all
shapes being displayed that are Ellipses with minor_axis greater than
7. Using your approach, we have to modify Shape, to add these two
function members to it, so that all Shapes can accept the minor_axis
function member. But the whole idea of extensibility of this sort is
that it should not be necessary to modify the base class. After all,
the base class might have been written by someone else; new versions
of it might be issued, and then you'd have to merge in all your local
changes (like minor_axis) every time, etc.
I don't think there's an obvious quick fix for this issue, but I do
think it's worthy of being acknowledged as a problem.garry@ithaca.uucp (Garry Wiegand) (02/21/91)
sdm@cs.brown.edu (Scott Meyers) writes: >In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes: >| All you have to do is make a virtual function diameter() for all Shapes. > > class Arc { ... }; > class ControlArc: public Arc { ... }; > class DataArc: public Arc { ... }; > class NPControlArc: public ControlArc { ... }; > >... How can they do this if all they have is a set of Arc pointers? In >this case, I could provide a virtual function called draw, but in general >an application might want to do something I've never heard of, so there >will be no virtual function for them to call. That being the case, there >needs to be a way to find out the "real" type of the Arc pointer, so they >can do the appropriate thing. This "isKindOf" argument keeps coming up. Perhaps the problem should be attacked the other way: what would it take to allow an application to add a virtual function to an existing class (for which the application programmer doesn't have source)? First thoughts: A) Allow "change type of". The application can now derive a new class from each library class and add its virtual function. If the application does all of the instance-creating, and only creates derived objects, things work out. *But* if the library creates one of the instances, the instance's virtual function table won't be the one the application wants. So: allow some syntax for an base class instance to be *actually changed* into a derived class instance. Doesn't work if the derived class requires extra instance variables (can't change the size without considerable trickiness). *Does* work (the v-table pointer is switched) for extra virtual functions. (The symmetric operation (derived class to actual base class) should also be legal, but right now I don't see the utility.) B) Never use "new" in a library. Always allow the application to do the allocating, thereby avoiding the problems with "if the library creates an instance". This can be implemented with the current C++. This could be made formal with syntax of the form "for the duration of this block, please override the constructor of class foo". (Even more generally, allow a class itself to be passed in as an argument -- promote classes to first-class objects. Eek - Smalltalk!) C) Continuing the train of thought, back in C++-land, allow "class augmentation" at least for virtual functions. This means loosening the requirement that all modules agree exactly on the declaration of a class. In particular, allow the v-table to grow to allow a limited run-time binding of virtual functions. Virtual functions known at compile-time of the constructor of the class would work as now. A new mechanism would be implemented to allow other modules to incorporate in their own "deferred" virtual functions for that class during their own initialization; functions that the constructor module didn't know about. I can think of several methods of implementation, all of them great fun :-). The more general case of allowing instance functions AND instance variables to be added to the class is also do-able. D) I don't have a D). Suggestions? Garry Wiegand --- Ithaca Software, Alameda, California ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net
jonas@falcon.ericsson.se (Jonas Nygren) (02/21/91)
In article <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >In article <1190@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: >>> aed@netcom.COM (Andrew Davidson) >>> I have some processing that only applies for certain types of objects. >>> If an object is not of the correct type I want to do some error stuff. >>> The problem is how do I fiqure out what the type of the object is. Simula have dynamic typechecking and also an operator 'in' which could be used to achieve exactly what you want. In the C++ world I believe that the NIH library do type all objects and this mechanism would probably also solve your problem. The mechanism in NIH is a bit akward to use (my personal opinion) but you do not have to invent your own scheme. (I do not know were you can find NIH). /Jonas
sabbagh@acf5.NYU.EDU (sabbagh) (02/22/91)
garry@ithaca.uucp (Garry Wiegand) writes: >This "isKindOf" argument keeps coming up. Perhaps the problem should >be attacked the other way: what would it take to allow an application >to add a virtual function to an existing class (for which the >application programmer doesn't have source)? Unfortunately, much of this discussion has been abstract, in the sense that "C++ should provide the ability to check a class type at run-time". My basic counter-argument is: why? If the application calls for run-time type checking, then it can be built into the system using C++. Its not particularly easy, but it is not wasted effort, SINCE THE DESIGN CALLS FOR THIS ABILITY. This would come up in database applications, graphics, etc. where the end-user needs to select objects at run-time. >A) Allow "change type of". The application can now derive a new class > from each library class and add its virtual function. If the > application does all of the instance-creating, and only creates > derived objects, things work out. *But* if the library creates one > of the instances, the instance's virtual function table won't be the > one the application wants. > So: allow some syntax for an base class instance to be *actually > changed* into a derived class instance. Doesn't work if the derived > class requires extra instance variables (can't change the size > without considerable trickiness). *Does* work (the v-table pointer > is switched) for extra virtual functions. > (The symmetric operation (derived class to actual base class) should > also be legal, but right now I don't see the utility.) > This suggestion is already in C++; its called "inheritance". The client programmer (person who is using the library) call inherit from the supplied classes, providing whatever additional virtual functions s/he likes. I agree, however, that it is hard to decide which member functions to make virtual; but this too can be worked around. Finally, general observations. C++ was originally designed to augment the C with object-oriented capabilities and other facilities to make programming-in-the-large easier. C was intended as a systems language; C++ still hold true to this. If you are looking for a fully interpreted environment in which everything is an object, use Smalltalk. If you want to build applications on a wide variety of hardware and software platforms and want better productivity than offered by C, use C++. You can implement Smalltalk (or CLOS, or whatever) in C++, but then you would be implementing an intrepreter, not an easy task in any language. Hadil G. Sabbagh E-mail: sabbagh@cs.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 "Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr. Disclaimer: This is not a disclaimer.
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/22/91)
In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >What do you care what the committee says? If you must have this feature, >write, in the baseclass > > virtual const char* myType() = 0; > >then do > >const char* ControlArc::myType() { return "ControlArc";} > >It is already in the language if you must have it. This is the programmer supporting it, not the language. It is "possible" but as you point out, not controllable. >However, I would still discourage you from this type of programming. Pun intended ? >Why? Because people will add new types of Arcs and you won't deal with >them properly. You're dealing with objects based on an exact match of >some type string instead of based on some relevant attribute that a >virtual function could return. You're wiring in a list of classes you >can handle, requiring more code rewriting as classes are added. Right on. This why a simple typeof() won't do either. It is possible to build a more consistent way to tell what an object can really do, (e.g. x.hasmember("diameter")) but this is only marginally better since you are still requiring code to be rewritten and deal with the names, which you supposedly already dealt with in the class header. As you point out, this form of programming is unreliable unless others consistently point out your convention. Is has a far worse flaw, however, which also applies to defining a virtual function normally: it is not possible for the base class programmer to anticipate everything that will be done by the derived class programmers. It is ridiculous to say that the solution is to add a diameter of null value, or a virtual that does nothing, in the base type "shape". It is CIRCLE's problem, but as C++ works now CIRCLE can't solve it. So shape ends up dealing with all of its derived type's problems. And code reusability is a myth. A simple free function like is_legal(x.diameter) which could be partially resolved at compile-time, and set up simple tables (like virtuals do) to deal with remaining (runtime) ambiguities in the type. One could apply the same mechanism to builtins, to say things like is_legal(5/2). With this, my code need only depend on a very few operations, and not on anything's type. The type system is in this case a great convenience to the compiler, which can resolve my questions very efficiently. By the way, ANSI is already starting to discuss some form of a type tag, apparently, since exceptions seem to require it anyway. >But if you really want to do it, you can, so stop saying that C++ won't >give you run-time type information. It's trivial to add if you want it. I disagree. It's possible (although not trivial to maintain) IF AND ONLY IF you are in source-code control of all of the types you derive from, which one would hope (if we are reusing software) is not the case. C++ needs to deal with this. -- 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
grue@batserver.cs.uq.oz.au (Frobozz) (02/22/91)
In <27C2D580.3B49@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>But in more intelligent O-O languages, asking the type, or better, >>asking if there is a diameter, is a fundamental operation in type >>Object that all objects can do. >C++ is statically typed. And there is no requirement that all classes >be derived from a hypthetical Object class. So the features you desire >cannot be accomplished in C++. >BTW, I happen to find C++ an excellent tool for _exactly_ those >reasons. I pay only for those OOP features I need, and no more. And if you go all the way back to Simula, you find that type asking is permitted (as is asking if something is a type or sub-type). Simula doesn't have a type object from which everything comes. Simula does maintain some prorgammer invisible type information which is quite anti the principles of C. So I don't suggest adding this feature to C++ (the programmer can always do it themselves). Pauli seeya Paul Dale | Internet/CSnet: grue@batserver.cs.uq.oz.au Dept of Computer Science| Bitnet: grue%batserver.cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%batserver.cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@batserver.cs.uq.oz | UUCP: uunet!munnari!batserver.cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@batserver.cs.uq.oz.au --
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/23/91)
In article <27C2D580.3B49@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>But in more intelligent O-O languages, asking the type, or better, >>asking if there is a diameter, is a fundamental operation in type >>Object that all objects can do. > >"More intelligent"? Your prejudices are showing. :-) Other languages support a syntax with fewer seams, and resolve efficiency issues with an optimizer. C++ deliberately doesn't do this and leaves it in the hands of the programmer, therefore C++ as a language decides that it will be less intelligent and force programmers to be more intelligent. Although this may be a compliment to C++ programmers, it is also more work for them, and it may be unnecessary in some places. I didn't really think of this as a prejudice, just a statement of fact. >C++ is statically typed. And there is no requirement that all classes >be derived from a hypthetical Object class. So the features you desire >cannot be accomplished in C++. Nonsense. There is absolutely no reason that the compiler cannot determine that *circle* has a diameter at compile-time, indeed it MUST know that. A macro/function/who-cares like x.has_member(diameter) can be completely optimized away at runtime where the type is unambiguous. Where it is ambiguous, the cost is exactly the same as a virtual function which was your alternate solution, but one which would require me to change the base class shape, which is unacceptable. >BTW, I happen to find C++ an excellent tool for _exactly_ those >reasons. I pay only for those OOP features I need, and no more. Nobody is suggesting a compromise to this principle. >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
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/23/91)
In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes: >craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >> >>imagine a database query: >> >> "from the list of shapes, show me all the circles of diameter > 30" > >All you have to do is make a virtual function diameter() for all Shapes. This solution has been rejected already by several people here, so I won't repeat the reasons except to say that I don't own Shape but own several of its subclassees. >A function which expects to operate on a class of type Shape may >reaonably expect all the functionality of Shape to be present. It may >not reasonably expect specific behaviors of classes derived from Shape >to be present. Part of being a "pointer to Shape" is the ability to point to subclasses. All virtual functions guarantee is to support the same interface, not the same behavior. Clearly quite different things will happen when different shapes are "stretched", for instance. >If checking diameters of a Shape is something you would expect to do, >then Shape should have a virtual function diameter(). There would be Absolutely not. Shapes in general do not have diameters. >defined behavior (such as return 0 or throw an exception) for classes >which do not have diameters (i.e., a Shape which is not closed). And I do not want to create a type bureacracy problem (i.e. reorganizing all the types) every single time I have a small or incidental need to distinguish something. This is a very large solution to a very small problem, as is adopting an entire base class library, as some others have suggested doing. >But if from class Shape you derive ClosedShape and OpenShape, and have >a diameter only for a ClosedShape, you have no business looking for a >diameter on a list of Shapes -- only on a list of ClosedShapes. This >is all part of the system design. I don't need a lecture on OO design. :) I've been doing it since early '86, and C++ is the first language I've seen that enforces this approach dogmatically and refuses to acknowledge the obvious situations where it is preferable to test for type than reorganize the entire type matrix. It is a mistake, and even Stroustrop and Koenig apparently acknowledge that something must be done about it (I'm told they prefer the conditional-cast solution) >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
warren@cbnewsh.att.com (warren.a.montgomery) (02/23/91)
It seems impossible to satisfy everyone here, since the real problem is that any implementation capable of supplying type information given only an anonymous pointer must be keeping type information (overhead) in every object. One step that could be taken, though, would be to provide some standard way for the writer of a class to generate run-time type information where they do it. What I am talking about is a standard way of generating a standard member containing a pointer to a class structure describing the members (functions and data) of the object in some standard way. I've looked at some library code (NIH, I think) that does this by severe abuse of the pre-processor. This kind of stuff works, but it's error prone and not reliable. If there were a standard way of generating symbolic information like this and a standard for how it was to look, I think that the result would go a long way towards satisfying the needs of people who have seen the power that this information gives Lisp and Smalltalk, and find it lacking in C++. -- Warren Montgomery att!ihlpf!warren
chip@tct.uucp (Chip Salzenberg) (02/24/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >Part of being a "pointer to Shape" is the ability to point to subclasses. >All virtual functions guarantee is to support the same interface, not >the same behavior. Clearly quite different things will happen when >different shapes are "stretched", for instance. If the "same" operation is actually several operations that are distinct in semantic terms (as opposed to implemention), then folding them together into one virtual function is a design error. Perhaps the theoretical "stretch()" function needs to be split up into several virtual functions. >... even Stroustrop and Koenig apparently acknowledge that something must >be done about it (I'm told they prefer the conditional-cast solution) I would appreciate some details on "the conditional-cast solution." -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "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)
chip@tct.uucp (Chip Salzenberg) (02/24/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27C2D580.3B49@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>"More intelligent"? Your prejudices are showing. :-) > >Other languages support a syntax with fewer seams, and resolve efficiency >issues with an optimizer. C++ deliberately doesn't do this and leaves >it in the hands of the programmer, therefore C++ as a language decides that >it will be less intelligent and force programmers to be more intelligent. Ah, that kind of intelligence. I had understood it to mean "the choice of an intelligent programmer," which is of course quite a different implication. >>C++ is statically typed. And there is no requirement that all classes >>be derived from a hypthetical Object class. So the features you desire >>cannot be accomplished in C++. > >Nonsense. There is absolutely no reason that the compiler cannot determine >that *circle* has a diameter at compile-time, indeed it MUST know that. Given -- at compile time, and the point in the source code where construction takes place. > x.has_member(diameter) can be completely optimized away at runtime where > the type is unambiguous ... I would contest the utility of the specific proposal of "has_member()" for C++. In C++, a member name does not sufficiently distinguish a class. Consider two subclasses of Object, called Circle and Planet. A circle's diameter is measured in pixels, a planet's in kilometers. If you know that a given Object "has_member(diameter)", do you have a Planet or a Circle, or perhaps something entirely different? To which type should you cast your Object*, to Planet* or Circle*? You cannot know for certain. The proposal for "has_member()" falls into the Objective-C/Smalltalk "all messages [and member functions] are alike" trap, along with its characteristic weak point of encouraging a global mapping of name to magic number, which causes complications for separate compilation, especially for pre-compiled libraries. >>I pay only for those OOP features I need, and no more. > >Nobody is suggesting a compromise to this principle. I disagree. The proposed "has_member()" function would require me to pay the cost of a virtual function table for each and every object that may someday be used as a base class, since the compiler cannot predict whether I or some other programmer will test for members of that class or its derived classes. The same argument applies to any dynamic "this is my _real_ type" information kept by the compiler. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "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)
connolly@livy.cs.umass.edu (Christopher Connolly) (02/25/91)
In article <27C6DBF3.28A3@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >If the "same" operation is actually several operations that are >distinct in semantic terms (as opposed to implemention), then folding >them together into one virtual function is a design error. ^^^^^^^^^^^^ I don't think this is necessarily the case. For example, I am implementing, in C++, polynomial arithmetic over (somewhat) arbitrary coefficient fields. Since I have little control over how the user might wish to express those coefficients, I have to be prepared for quite a few combinations of coefficient types (ints, extended precision ints, rationals, algebraic numbers, other polynomials, etc.). Moreover, I have to check these coefficient types at runtime (as the user types the expressions in). Consider the operation "+": I can use simple integer addition if both my coefficients are integers. The "+" operation results in an integer in this case. On the other hand, adding an integer to an algebraic number usually results in another algebraic number. Integer addition and algebraic number addition are quite different algorithms, producing quite different results. Since integer arithmetic is much cheaper than algebraic number arithmetic, it would be a design error for me to coerce all the results of addition to algebraic numbers. I see no way around defining a generic "+" operation which takes different data types, and returns different data types as a result (all derived from the "coefficient" class, of course).
chip@tct.uucp (Chip Salzenberg) (02/26/91)
According to connolly@livy.cs.umass.edu (Christopher Connolly): >In article <27C6DBF3.28A3@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>If the "same" operation is actually several operations that are >>distinct in semantic terms (as opposed to implemention), then folding >>them together into one virtual function is a design error. > ^^^^^^^^^^^^ > >Consider the operation "+": I can use simple integer addition if both >my coefficients are integers. The "+" operation results in an integer >in this case. On the other hand, adding an integer to an algebraic >number usually results in another algebraic number. Integer addition >and algebraic number addition are quite different algorithms, >producing quite different results. But both of those algorithms implement "addition" in the sense that a mathemetician may use the word. So I probably would not consider your example to be an implementation of "several different operations [that are] distinct in semantic terms." >I see no way around defining a generic "+" operation which takes >different data types, and returns different data types as a result >(all derived from the "coefficient" class, of course). Sure. Make coefficient an abstract base class. Derive int_coeff (integer) and alg_coeff (algebraic). Have all "+" operations return a coefficient, thus allowing you to use the virtual function mechanism. Make a virtual member function "operator +=", and implement a non-member "operator +" using "+=". Then, the key: a virtual member function "int integer_value(int &n)", which sets "n" to the integer value of the given coefficient and returns true for success, or false for failure. Only int_coeff will define this function to return true; all others will return false. Then use it: coefficient c = coefficient(4) + coefficient(7); int n; if (c.integer_value(n)) cout << "c is " << n << "\n"; else cout << "c isn't an integer!\n";
jimad@microsoft.UUCP (Jim ADCOCK) (02/26/91)
In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: |In article <65451@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes: ||> The bottom line is that virtual functions are wonderful things and can ||> almost always be used to achieve what you want, but there are times when ||> you truly *do* need to get type information as you run. | |Scott then goes on to talk about how the ANSI committee is unlikely |to give him what he wants. | |What do you care what the committee says? If you must have this feature, |write, in the baseclass | | virtual const char* myType() = 0; | |then do | |const char* ControlArc::myType() { return "ControlArc";} | |It is already in the language if you must have it. However, I would still |discourage you from this type of programming. A "trivial" solution to the run-time type problem ought to be closer to O(1) than O(N), where N is the number of classes that need to have some notion of run-time type. Today, as far as I can figure out, C++ offers no way to write the run-time type stuff once in some superclass, and then have subclasses do the right thing. Although, using macros you can probably get this down to a one-line macro hack per derived class. Thus, I'd say C++ enables, but does not support, run-time type approaches. |Why? Because people will add new types of Arcs and you won't deal with |them properly. You're dealing with objects based on an exact match of |some type string instead of based on some relevant attribute that a |virtual function could return. You're wiring in a list of classes you |can handle, requiring more code rewriting as classes are added. I agree that relying on exact type testing is bad. But I don't agree that relying on inexact type testing is bad. Rather, I find it necessary in a wide variety of situations. Also, without language support, each library will implement its own notion of run-time type, generally precluding mixed-use of those libraries. I'd like to see consideration of some standard features in support of run-time type.
chased@rbbb.Eng.Sun.COM (David Chase) (02/26/91)
In article <70870@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >A "trivial" solution to the run-time type problem ought to be closer >to O(1) than O(N), where N is the number of classes that need to have >some notion of run-time type. ... >I'd like to see consideration of some standard features in support of >run-time type. Do note that (using algorithms known to me) run-time type-checks and subtype queries can be implemented much more efficiently in the single-inheritance case. This doesn't directly help C++, unless you choose to limit the problem that you are trying to solve. IF you use the single-inheritance model, "S subtype of T?" can be answered in O(1) time, given O(N) off-line preprocessing which yields an O(N) sized data structure. Answering "nearest supertype of S in {T1,...,TM}?" can be answered in O(logM) time, given (in addition to the above preprocessing) O(MlogM) preprocessing which yields an O(M) sized data structure. The algorithms to do this can be extracted from a paper by Dietz (I think), but I don't have the citation immediately available. Compiler/linker/run-time support is useful in solving this problem, by the way. David Chase Sun
jimad@microsoft.UUCP (Jim ADCOCK) (02/27/91)
In article <1991Feb21.182349.19132@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: |In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: .... |>Why? Because people will add new types of Arcs and you won't deal with |>them properly. You're dealing with objects based on an exact match of |>some type string instead of based on some relevant attribute that a |>virtual function could return. You're wiring in a list of classes you |>can handle, requiring more code rewriting as classes are added. | |Right on. This why a simple typeof() won't do either. It is possible |to build a more consistent way to tell what an object can really do, |(e.g. x.hasmember("diameter")) but this is only marginally better since |you are still requiring code to be rewritten and deal with the names, |which you supposedly already dealt with in the class header. You guys are arguing against bad implementations, not a bad idea. One doesn't want to test against an exact type as Joe points out, since one then cuts off the possibility of using polymorphism and further derived classes. One doesn't want to test against an exact member match as Craig points out, because then you're dealing with individual member names, and, unlike Smalltalk, C++ doesn't match methods based on name anyway. Two independent classes can both have a member "doSomething()" and the name matching could be totally accidental, and mean totally different things, and the two authors of those independent classes may have absolutely no intention that their two classes be intermixed. We don't want to reinvent the Smalltalk situation where accidental matching of methods occur. What we do want however, and what does make sense [IMHO :-] is to be able to test for "protocol" -- to see if a particular object matches a particular protocol. A "protocol" being the a set of methods that are matched -- which is the C++ concept, verses single method matching ala Smalltalk. So, given an otherwise unidentified object -- perhaps an object one is deserializing, one might want to ask: "Does this object respond to the foobar protocol, in which case maybe I want to allow access to this object as-if a foobar?" In C++, then, in order to be able to communicate to an object, you need to be able to ask questions about its protocol. A suitable method name might be a virtual IsSomeKindOf(Protocol): if (unidentifiedDeserializingObject->IsSomeKindOf(Protocol("FooBar"))) { doFooBarThingsWith(unidentifiedDeserializingObject); } Since protocols are inherited from some base class, some people conceptualize this slightly differently: if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar"))) { doFooBarThingsWith(unidentifiedDeserializingObject); } [In the above examples I immediately cast away from the "FooBar" strings lest anyone make the mistake to think I am suggesting that strings are the right way to represent such information. Ideally, one should be able to directly use a subclass name, rather than a string representation of that name, or some other additional/incompatible representation.]
dsouza@optima.cad.mcc.com (Desmond Dsouza) (02/27/91)
In article <8608@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: > In article <70870@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >A "trivial" solution to the run-time type problem ought to be closer > >to O(1) than O(N), where N is the number of classes that need to have > >some notion of run-time type. ... > > >I'd like to see consideration of some standard features in support of > >run-time type. > > Do note that (using algorithms known to me) run-time type-checks and > subtype queries can be implemented much more efficiently in the > single-inheritance case. This doesn't directly help C++, unless you > choose to limit the problem that you are trying to solve. > > IF you use the single-inheritance model, > > "S subtype of T?" > > can be answered in O(1) time, given O(N) off-line preprocessing which > yields an O(N) sized data structure. If you compute the transitive closure of the inheritance relationship and storing that, you have O(N^2) storage for O(1) response with N classes. For single inheritance, you can get an O(1) response with a O(logN) data structure per class i.e. O(NlogN) in all. Is there something better than that? Could you post a reference? Multiple inheritance, as well as dynamically extending the inheritance relationship (e.g. loading new derived classes) complicate matters. -- Desmond. -- ------------------------------------------------------------------------------- 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
nvi@mace.cc.purdue.edu (Charles C. Allen) (02/27/91)
In article <70902@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes: > Smalltalk, C++ doesn't match methods based on name anyway. Two independent > classes can both have a member "doSomething()" and the name matching > could be totally accidental, and mean totally different things, and > the two authors of those independent classes may have absolutely no > intention that their two classes be intermixed. We don't want to reinvent > the Smalltalk situation where accidental matching of methods occur. Perhaps you could explain the exact problem here. I agree that two "doSomething" methods can mean different things, I just don't understand the problem in the context of this discussion. > Since protocols are inherited from some base class, some people conceptualize > this slightly differently: > > if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar"))) > { > doFooBarThingsWith(unidentifiedDeserializingObject); > } You seem to imply that Smalltalk cannot do this. Smalltalk knows both the class of any given object and the class hierarchy, so it can certainly determine whether or not an object is "a kind of" FooBar: anObject isKindOf: Foobar. Charles Allen Internet: cca@physics.purdue.edu Department of Physics HEPnet: purdnu::allen, fnal::cca Purdue University Bitnet: cca@fnal.bitnet 1396 Physics Building West Lafayette, IN 47907-1396 talknet: 317/494-9776
Reid Ellis <rae@utcs.toronto.edu> (02/28/91)
In <1991Feb21.182349.19132@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >Right on. This why a simple typeof() won't do either. It is possible >to build a more consistent way to tell what an object can really do, >(e.g. x.hasmember("diameter")) but this is only marginally better since >you are still requiring code to be rewritten and deal with the names, >which you supposedly already dealt with in the class header. > >As you point out, this form of programming is unreliable unless others >consistently point out your convention. Is has a far worse flaw, however, >which also applies to defining a virtual function normally: it is not >possible for the base class programmer to anticipate everything that will >be done by the derived class programmers. It is ridiculous to say that >the solution is to add a diameter of null value, or a virtual that does >nothing, in the base type "shape". It is CIRCLE's problem, but as C++ >works now CIRCLE can't solve it. So shape ends up dealing with all of its >derived type's problems. And code reusability is a myth. The below solution has the two advantages of (a) being very straightforward to code and understand, and (b) being user-extensible in a hierarchical manner. shape.h: // I know the 'extern's aren't neccessary, but I like them. // extern class Circle; extern class UserDefined; // I like 'struct' too, so sue me // struct Shape { virtual Circle *asCircle() { return NULL; } virtual UserDefined *asUserDefined() { return NULL; } } circle.h: struct Circle : Shape { Circle *asCircle() { return this; } } myUserCode.h: extern class Whatever; struct UserDefined : Shape { UserDefined *asUserDefined() { return this; } virtual Whatever* asWhatever() { return NULL; } } This way, if you get a Shape '*s', you can say: Circle *c; if((c = s->asCircle()) != NULL) { // do circle things.. UserDefined *ud; Whatever *w; if((ud = s->asUserDefined()) != NULL && (w = wd->asWhatever()) != NULL) { // do Whatever things.. Actually, if you want to define these things as *never* being allowed to fail [i.e. they will only be called when the application's state *DEMANDS* that they be the type requested, then rather than returning NULL, you can make the base class ASSERT fail, or perr() or whatever. Then you can write code like: shape->asUserDefined()->asWhatever()->whateverMethod(param); Yes, it's typesafe downcasting.. Reid -- Reid Ellis 176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada rae@utcs.toronto.edu || rae%alias@csri.toronto.edu CDA0610@applelink.apple.com || +1 416 446 1644
jimad@microsoft.UUCP (Jim ADCOCK) (03/01/91)
In article <8608@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: |In article <70870@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: |>A "trivial" solution to the run-time type problem ought to be closer |>to O(1) than O(N), where N is the number of classes that need to have |>some notion of run-time type. ... | |Do note that (using algorithms known to me) run-time type-checks and |subtype queries can be implemented much more efficiently in the |single-inheritance case. This doesn't directly help C++, unless you |choose to limit the problem that you are trying to solve. Sorry, I guess I made myself pretty unclear. I meant to imply O(N) programmer effort -- not O(N) time. Given N classes, the programmer is going to have to specify type information in O(N) places. Clearly this is a violation of encapsulation. If C++ "supported" run-time typing, the programmer ought to be able to specify the needed run-time information in O(1) places -- in a single superclass, for example. This could be done if C++ provided a way to specify some "templated" information in a superclass, with that template expanded "automatically" without programmer intervention in all subclasses. But, the present template definitions don't seem to allow for such a possibility. Correct me if I've missed something.
craig@gpu.utcs.utoronto.ca (Craig Hubley) (03/03/91)
In article <6900@mace.cc.purdue.edu> nvi@mace.cc.purdue.edu (Charles C. Allen) writes: >In article <70902@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes: >> Smalltalk, C++ doesn't match methods based on name anyway. Two independent >> classes can both have a member "doSomething()" and the name matching >> could be totally accidental, and mean totally different things, and >> the two authors of those independent classes may have absolutely no >> intention that their two classes be intermixed. We don't want to reinvent >> the Smalltalk situation where accidental matching of methods occur. > >Perhaps you could explain the exact problem here. I agree that two >"doSomething" methods can mean different things, I just don't >understand the problem in the context of this discussion. Not to speak for Jim, but two methods speed() could mean something very different when applied to a ship (speed over water measured in knots) and an airplane (airspeed measured in km/h). Ideally one would be returning values typed as knots and km/h, with conversions where (and if) appropriate. However, now knowing that there is a member speed() means nothing unless you know that it has a "speed in knots" or "knots speed()". This means you have to go past the name, to find out "what the name returns" or "what arguments it takes" or "what class it comes from". This latter is the most usual solution, that is, I can differentiate "speed as a ship" from "speed as a plane". This is only possible in C++ now if you know that you are descended from both. And there is no way to find this out at runtime (ruling out changes to the base classes). I agree, by the way, that the "test for member" should include some way to test the origin (base class) or protocol (return & arguments) of that member. >> Since protocols are inherited from some base class, some people conceptualize >> this slightly differently: >> >> if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar"))) >> { >> doFooBarThingsWith(unidentifiedDeserializingObject); >> } This forces FooBar to support the FooBarThings without exception, even though C++ permits private (implementation) inheritance. I assume that Jim means "IsSomePublicSubClassOf(Class("FooBar"))". >You seem to imply that Smalltalk cannot do this. Smalltalk knows both >the class of any given object and the class hierarchy, so it can >certainly determine whether or not an object is "a kind of" FooBar: > > anObject isKindOf: Foobar. Certainly. This is differentiating the "exact" type from the "base" types. Things get a little more complicated when multiple inheritance is involved, as others have pointed out the lookups can be more complex: in general knowing the possible acceptable types of the passed object a compiler can resolve such a lookup down to no more than a virtual function call and possibly to nothing: e.g. the above would compile to "true" if anObject was passed as a Foobar... it would only be accepted if it was a Foobar or descendant of Foobar) I agree in general with the idea of "protocols" but these can be implemented in C++ now as pure virtual abstract base classes which are inherited publicly. When I teach C++ this is the preferred way of sharing behavior, and I try to untangle it from the implementation inheritance C++ tends to emphasize. In my view the "unified" hierarchy that factors both external behavior and internal implementation is quite difficult to build beyond a few layers deep, and keeping them separate permits quite a bit more flexibility to both the producer and consumer. Some languages, such as Trellis, take this to an extreme and support implementation inheritance except as a default. I believe this issue (whether to have separate behavior/implementation hierarchies) has been beaten to death in comp.object, so I won't repeat it. My own position is "yes, but sometimes you can safely avoid it" where the definition of "safe" varies with circumstances. C++ has a pseudo-protocol, the pure virtual abstract base class, consisting of function signatures. However, since in C++ inheriting classes cannot vary these signatures even in type safe ways (more specific return types, more general arguments), and cannot determine which of several possible protocols is likely to be invoked (no type tag or base class lookup), or even if then protocol being invoked is likely to cause an error, the utility of the protocol approach is severely (and IMHO unnecessarily) restricted. With no way to specialize signatures or differentiate between protocols, C++ programmers are more or less forced to add virtual functions one at a time as they build subclasses. When the signature must differ from that defined in an earlier class, a new name must be invented. Therefore the "protocol" will necessarily be larger, and spread across several classes rather than concentrated in one, as a direct consequence of the way C++ forces these classes to be built. Defining a true protocol in C++, with signatures that could be overridden in type-safe ways, might overcome some of these problems and help make external behavior more predictable and encourage polymorphism over brand-new functions in each subclass. It ain't everyone's cup o' tea, but it needn't inconvenience them any. -- 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
jimad@microsoft.UUCP (Jim ADCOCK) (03/05/91)
In article <6900@mace.cc.purdue.edu> nvi@mace.cc.purdue.edu (Charles C. Allen) writes: |In article <70902@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes: |> Smalltalk, C++ doesn't match methods based on name anyway. Two independent |> classes can both have a member "doSomething()" and the name matching |> could be totally accidental, and mean totally different things, and |> the two authors of those independent classes may have absolutely no |> intention that their two classes be intermixed. We don't want to reinvent |> the Smalltalk situation where accidental matching of methods occur. | |Perhaps you could explain the exact problem here. I agree that two |"doSomething" methods can mean different things, I just don't |understand the problem in the context of this discussion. One of the original authors suggested that what was being proposed was a way to test whether an object supported an individual method or not. He then went to to argue way such support is bad. I counter-argued that what is really needed is neither the ability to test whether an object supports some particular method, nor the ability to test whether an object is some exact type, but rather, what is needed is the ability to test whether an object supports some particular protocol. |> Since protocols are inherited from some base class, some people conceptualize |> this slightly differently: |> |> if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar"))) |> { |> doFooBarThingsWith(unidentifiedDeserializingObject); |> } | |You seem to imply that Smalltalk cannot do this. Smalltalk knows both |the class of any given object and the class hierarchy, so it can |certainly determine whether or not an object is "a kind of" FooBar: | | anObject isKindOf: Foobar. I did not mean to imply that Smalltalk can't do this. I meant to imply that Smalltalk also supports exact type testing, and even worse, supports testing whether or not an object has a particularly named method. I agree that using such overly restrictive tests is bad and greatly restricts code reuse. But, I is disagree that because supports- method testing and exact-type testing are bad means we should not support *any* notion of run-time type testing in C++. On the contrary, in C++ one needs to know if a particular unidentified objects supports a particular protocol before you can do something reasonable with it. I think its quite reasonable to have objects in a context where they do not have support the necessary protocols to be used in that context -- it just means that the object cannot be accessed via that context. A silly example might be that of an IC-layout program. The database of objects may include things that are displayable, but which are not editable via the IC protocol. We'd still like to be able to include such objects in the database, and display them on the schematic diagram. But you wouldn't be able to edit them using the IC-editor -- since they don't support the IC protocol. Such objects presumably support a displayable-object protocol, but do not support an IC protocol.
jimad@microsoft.UUCP (Jim ADCOCK) (03/05/91)
In article <1485@acf5.NYU.EDU> sabbagh@acf5.NYU.EDU (sabbagh) writes: |garry@ithaca.uucp (Garry Wiegand) writes: | |>This "isKindOf" argument keeps coming up. Perhaps the problem should |>be attacked the other way: what would it take to allow an application |>to add a virtual function to an existing class (for which the |>application programmer doesn't have source)? | |Unfortunately, much of this discussion has been abstract, in the sense |that "C++ should provide the ability to check a class type at run-time". |My basic counter-argument is: why? | |If the application calls for run-time type checking, then it can be built |into the system using C++. Its not particularly easy, but it is not |wasted effort, SINCE THE DESIGN CALLS FOR THIS ABILITY. This would come |up in database applications, graphics, etc. where the end-user needs |to select objects at run-time. To restate your question: Why should C++ actively support runtime type testing when the issue keeps coming up again and again, and when with great difficulty individual applications can create it for themselves. Answer: C++ should actively support runtime type testing because the issue keeps coming up again and again and it takes great difficulty for individual applications to create it for themselves. Even if individual applications do create run-time type systems for themselves, such systems are unique to a particular application or set of libraries and thus prevent code from being reused. Conversely, if C++ offered the required template support to make implementing run-time type implementations easy, then C++ could be said to "support" run-time type testing even if such run-time type testing weren't built into the language. It could be handles by libraries instead. You'd still need a standard to specify how those libraries should work. "C" *could* be used for OOP -- but it would require awkward, ugly, error prone hacks every where in order to do "virtual" functions. Thus, we say C does not *support* OOP. Likewise, today we say C++ *supports* OOP, but it does not *support* run-time type checking. |Finally, general observations. C++ was originally designed to augment |the C with object-oriented capabilities and other facilities to make |programming-in-the-large easier. C was intended as a systems language; |C++ still hold true to this. I disagree. I see C++ as a general-purpose compiled OOPL with wide applicability in that arena. I believe many more people are using C++ for creating applications than are using C++ for systems. This was also true for C. The fact that the original authors were involved in systems design meant that they appreciated a language that can be compiled to excellent quality code. But these same capabilities are required for competitive applications today. |If you are looking for a fully interpreted |environment in which everything is an object, use Smalltalk. If you |want to build applications on a wide variety of hardware and software |platforms and want better productivity than offered by C, use C++. You |can implement Smalltalk (or CLOS, or whatever) in C++, but then you |would be implementing an intrepreter, not an easy task in any language. The implication being that run-time type testing requires an interpreter- like approach, or that adding run-time type testing turns C++ into a Smalltalk or a CLOS. I disagree. What is needed is better compiler support. My preferred solution to this problem is to improve the capabilities of templates, such that derived classes can automatically expand some methods specified in the base class via the sole action of being derived. Failing such improvements to templates, I'd like to see agreement among vendors about the "right" way to support run-time type checking -- so that N dialects don't spring up -- and they will, because the issue of run-time type testing keeps coming up over and over again. This is like multiple inheritence. Good implementations don't make you pay extra cost for multiple inheritence if you don't use it. So if you don't like it, don't use it. But if C++ didn't support multiple inheritance, then vendors would come up with multiple, independent, incompatible versions of it. Likewise run-time type testing. It can be implemented such that people who don't use it, don't pay for it. But if it isn't specified in that language, multiple incompatible dialects will spring up. Here's a simple example of where better template support is needed. This is really an example of run-time type information -- but few people would consider it "controversial." Let's say in a base class "Object" you require all subclass be able to tell you the size of their objects. You need to know their size for serialization, deserialization, whatever. Why can't you just specify such a virtual method in a base class, and have it automatically expanded via templates in all subclasses??? You'd think templates would provide such a capability, but they don't: class Object { .... public: // choose your favorite syntax for the below: template virtual int size() { return sizeof(this_class); } }; -- where the intent is that size() is a templated member function that is automatically expanded on any derivation from Object. Surprisingly, there doesn't seem to be any reasonable way of doing this via today's definition of templates. Which seems like a hole in the template definition to me!
chip@tct.uucp (Chip Salzenberg) (03/07/91)
According to jimad@microsoft.UUCP (Jim ADCOCK): >...what is really needed is neither the ability to test whether an >object supports some particular method, nor the ability to test whether >an object is some exact type, but rather, what is needed is the ability >to test whether an object supports some particular protocol. Even that isn't enough. Two unrelated types can both implement "void foo(int)". That doesn't mean that the two foos are equivalent. The "isKindOf" test is the minimum for reasonable dynamic typing in the C++ type forest. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
chip@tct.uucp (Chip Salzenberg) (03/07/91)
According to jimad@microsoft.UUCP (Jim ADCOCK): >C++ should actively support runtime type testing because the issue keeps >coming up again and again and it takes great difficulty for individual >applications to create it for themselves. I most certainly would _not_ agree that dynamic typing needs to be added just because "the issue keeps coming up". Maybe lots of people are making similar errors. Lots of Smalltalk, Objective C, CLOS, etc. programmers are converting to C++, and they are looking for language features like those of their previous languages so they can keep programming in the ways to which they are accustomed. This fact is not surprising. What they do not realize, however, is that C++ programming does not always admit of Smalltalk/Objective C/CLOS/etc. strategy. Some of them eventually get a clue. Many, however, never give up in trying to force the square C++ peg into the round dynamic-type-test hole. >The implication being that run-time type testing requires an interpreter- >like approach, or that adding run-time type testing turns C++ into >a Smalltalk or a CLOS. I disagree. It would not transform C++ into Smalltalk, true. But it would be a move in that direction, a move which is, in my opinion, entirely unnecessary. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
dsr@mir.mitre.org (Douglas S. Rand) (03/07/91)
In article <27D57565.2B22@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > According to jimad@microsoft.UUCP (Jim ADCOCK): > >C++ should actively support runtime type testing because the issue keeps > >coming up again and again and it takes great difficulty for individual > >applications to create it for themselves. > > I most certainly would _not_ agree that dynamic typing needs to be > added just because "the issue keeps coming up". Maybe lots of people > are making similar errors. > > Lots of Smalltalk, Objective C, CLOS, etc. programmers are converting > to C++, and they are looking for language features like those of their > previous languages so they can keep programming in the ways to which > they are accustomed. This fact is not surprising. > This is not entirely correct. I am a previous CLOS/Lisp programmer and I viewed it as a mistake to query an object for its type. The correct paradigm is to allow the object system to disambiguate the types, that's what it's there for. IMHO you are not getting the requests from SmallTalk et al but from naive C programmers who have never programmed using an OOP language before. This is a standard trap for new OOP programmers. > What they do not realize, however, is that C++ programming does not > always admit of Smalltalk/Objective C/CLOS/etc. strategy. Some of > them eventually get a clue. Many, however, never give up in trying to > force the square C++ peg into the round dynamic-type-test hole. > C++ strategy *is* Smalltalk/CLOS/Flavors strategy. The only difference is the richness of the environment. C++ is not a dynamic environment for most people (ParcPlace C++ is at least one counterexample), but the programming practice is basically similar. > >The implication being that run-time type testing requires an interpreter- > >like approach, or that adding run-time type testing turns C++ into > >a Smalltalk or a CLOS. I disagree. > > It would not transform C++ into Smalltalk, true. But it would be a > move in that direction, a move which is, in my opinion, entirely > unnecessary. > There is nothing which prevents a programmer from adding type testing to C++ classes now. Many real programs require some of this. You can add instance fields which get named in constructors, virtual functions which return values, all kinds of perfectly acceptable options are available to the programmer. -- Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ
connolly@livy.cs.umass.edu (Christopher Connolly) (03/08/91)
In article <27D57565.2B22@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >What they do not realize, however, is that C++ programming does not >always admit of Smalltalk/Objective C/CLOS/etc. strategy. Some of >them eventually get a clue. Many, however, never give up in trying to >force the square C++ peg into the round dynamic-type-test hole. To be fair, many of them *do* get the clue, but they have no choice in their working environment, short of looking for another job. One industrial group that I've been working with, for example, is now faced with the task of converting a few thousand CLOS functions into C++...no mean task. I'm not sure who's actually forcing the peg into the hole, but in this case it does not seem to be the people writing the code. The language decision was made elsewhere, by people who did not take the technical consequences seriously. C'est la vie.
johnb@searchtech.com (John Baldwin) (03/08/91)
jimad@microsoft.UUCP (Jim ADCOCK) writes:
! C++ should actively support runtime type testing because the issue keeps
! coming up again and again and it takes great difficulty for individual
! applications to create it for themselves.
chip@tct.uucp (Chip Salzenberg) responds:
! I most certainly would _not_ agree that dynamic typing needs to be
! added just because "the issue keeps coming up". Maybe lots of people
! are making similar errors.
And dsr@mir.mitre.org (Douglas S. Rand) responds:
! This is not entirely correct. I am a previous CLOS/Lisp programmer and
! I viewed it as a mistake to query an object for its type. The correct
! paradigm is to allow the object system to disambiguate the types,
! that's what it's there for.
.
.
.
! There is nothing which prevents a programmer from adding type testing
! to C++ classes now. Many real programs require some of this.
(Begging your pardon, but that seems to be a contradiction. :-} )
Perhaps what we have here is in fact a needed extension to the language
which, when not used judiciously, can be harmful. A good example in
vanilla (ANSI) C might be the goto, or worse, setjmp() and longjmp().
[I know: they're part of the LIBRARY, not of the language itself.
Consider, (A) The standard addresses them, and (B) All analogies break
down at some level. :-/ ]
Here's the real question: has anyone here needed type testing *for ANY
other reason* than,
1) to implement persistent objects, or
2) to allow run-time object selection?
If not, then maybe what we really need is simply language support for
persistence. I *know* how painful it is to implement a cohesive and
consistent object storage utility from scratch! Yes, when it was
finished, we had something which was (more or less) optimized for
our particular use, but there was no reason why the language or the
library could not have provided efficient *standardized* support for this.
On the other hand, if there are a sufficient number of other situations
where dynamic type testing is needed, then what we need is not only that
facility, but also a good understanding (in the form of widely known
style rules) of the proper way to use it, and of improper uses to avoid.
Both C and C++ are rife with constructs which, in the hands of a
"spaghetti coder," can produce a real nightmare, but which, when used
sparingly and judiciously by an experienced craftsman, can also result
in efficient, structured, easy-to-read code.
I guess before I can form an opinion or take a stand, I'd need to know
which is the actual case: dynamic typing needed directly by the programmer,
or just better support for persistence??
--
John Baldwin | johnb@searchtech.com
Search Technology, Inc. | srchtec!johnb@gatech.edu
Atlanta, Georgia | johnb%srchtec.uucp@mathcs.emory.educraig@gpu.utcs.utoronto.ca (Craig Hubley) (03/08/91)
In article <27D57565.2B22@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to jimad@microsoft.UUCP (Jim ADCOCK): >>C++ should actively support runtime type testing because the issue keeps >>coming up again and again and it takes great difficulty for individual >>applications to create it for themselves. >... >Lots of Smalltalk, Objective C, CLOS, etc. programmers are converting >to C++, and they are looking for language features like those of their >previous languages so they can keep programming in the ways to which >they are accustomed. This fact is not surprising. Yeah, lots of C programmers would be upset if such dangerous anachronisms as public data members went away, too. Problem is, people who are already using these other OO languages are already building reusable code libraries, and there is comparatively less experience with building such libraries in C++. We might want to listen to them tell us what they need. Especially if the only answer on "how to do it" coming from the C++ community is "add it as a virtual in the base class". I agree with the author who called this "laughable". From the perspective of binary-reusable libraries, anyway. >What they do not realize, however, is that C++ programming does not >always admit of Smalltalk/Objective C/CLOS/etc. strategy. Some of >them eventually get a clue. Many, however, never give up in trying to >force the square C++ peg into the round dynamic-type-test hole. Since C++ is the production language of choice for those building PROTOTYPES in Smalltalk and CLOS, at least, allowing easy conversion of components between these languages and C++ is an ongoing problem. Potentially one of great industrial importance, if prototyping this ways becomes more widespread. I see it happening in dozens of organizations right now... >>The implication being that run-time type testing requires an interpreter- >>like approach, or that adding run-time type testing turns C++ into >>a Smalltalk or a CLOS. I disagree. > >It would not transform C++ into Smalltalk, true. But it would be a >move in that direction, a move which is, in my opinion, entirely >unnecessary. But you probably don't prototype in Smalltalk and then ship in C++. And you didn't learn Smalltalk in school and now have to learn C++. And you have already said you don't believe much in binary-reusable libraries, or at least their usefulness in what you do. IMHO: Such opposition appears to be political: you don't want the language "hijacked" by "outsiders" by which you appear to mean people who aren't doing everything in C and liking it. I can understand why you won't accept arguments like "it's done that way in Smalltalk", but ANSI is not supposed to accomodate C programmers, it is supposed to cut costly re-invention and re-education (of/in things that should be standardized but aren't) for all of US industry. Prototyping in other OO languages and shipping in C++ is a fact of life. So is the preference for "pure" over "hybrid" languages in education. So is the desire for (and corporate commitment to) extend class hierachies without source access. At least a lot of firms are planning to waste big money trying, if waste it is. Given all these facts, it is a mighty big $ argument for making the change. So I don't see how political (i.e. interest-group) arguments can do anything but sanctify the "move towards Smalltalk", as you put it. There is a huge $ payoff for doing so, or at least many companies believe there is, or they wouldn't be interested in object-oriented systems (or possibly C++) at all. So please, let's continue this argument along technical grounds. -- 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
dsr@mir.mitre.org (Douglas S. Rand) (03/09/91)
In article <1991Mar8.024331.14235@searchtech.com>, johnb@searchtech.com (John Baldwin) writes: > > And dsr@mir.mitre.org (Douglas S. Rand) responds: > ! This is not entirely correct. I am a previous CLOS/Lisp programmer and > ! I viewed it as a mistake to query an object for its type. The correct > ! paradigm is to allow the object system to disambiguate the types, > ! that's what it's there for. > . > . > . > ! There is nothing which prevents a programmer from adding type testing > ! to C++ classes now. Many real programs require some of this. > > > (Begging your pardon, but that seems to be a contradiction. :-} ) > Well I suppose there is some contradiction here. I guess I'll reword my point. I feel that the times when a programmer attempts to directly disambiguate a type in an OOP program are mostly a mistake. As John Baldwin points out in his followon, a reasonable time to do this is when implementing a persistent storage scheme. Naive OOP programmers often make the mistake of doing things in programs which the object system support should be doing (usually in a more efficient manner). This doesn't mean that it is totally useless functionality. But, there is nothing which prevents all such reasonable extensions and work from happening right now with the language unchanged. You can get both the behavior of (class-of object) and (subtype x y) from writing virtual methods and providing initialized data in instance variables. -- Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ
vinoski@apollo.HP.COM (Stephen Vinoski) (03/09/91)
In article <1991Mar8.073356.25207@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >Such opposition appears to be political: you don't want the language >"hijacked" by "outsiders" by which you appear to mean people who aren't >doing everything in C and liking it. I can understand why you won't >accept arguments like "it's done that way in Smalltalk", but ANSI is >not supposed to accomodate C programmers, it is supposed to cut costly >re-invention and re-education (of/in things that should be standardized >but aren't) for all of US industry. Prototyping in other OO languages >and shipping in C++ is a fact of life. So is the preference for "pure" >over "hybrid" languages in education. So is the desire for (and corporate >commitment to) extend class hierachies without source access. At least a >lot of firms are planning to waste big money trying, if waste it is. > >Given all these facts, it is a mighty big $ argument for making the change. >So I don't see how political (i.e. interest-group) arguments can do anything >but sanctify the "move towards Smalltalk", as you put it. There is a huge $ >payoff for doing so, or at least many companies believe there is, or they >wouldn't be interested in object-oriented systems (or possibly C++) at all. IMHO there are many, many more C programmers looking at C++ as a way to reduce their development and maintenance costs than there are Smalltalk programmers looking at C++ as a way to turn their protoypes into real products. I'd be really surprised if the popularity of C++ was due to large numbers of converted Smalltalk programmers! Since many programmers use C for reasons of efficiency and program compactness, they will require the same from C++; costly OO features (in terms of memory space and run time) will cause them to avoid C++. I hope the evolution of C++ isn't controlled by $'s and politics, but if it is, Smalltalk programmers will lose, simply because there are many more C programmers using the language. -steve | Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | | HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | | "The price of knowledge is learning how little of it you yourself harbor." | | - Tom Christiansen |
chip@tct.uucp (Chip Salzenberg) (03/09/91)
According to dsr@mir.mitre.org (Douglas S. Rand): >IMHO you are not getting the requests [for a C++ isKindOf() feature] >from SmallTalk et al but from naive C programmers who have never >programmed using an OOP language before. Whatever my disagreements with Craig Hubley, I would never call him a "naive C programmer". On the other hand, it is true that the first instinct of a C programmer faced with C++ dynamic type loss -- i.e. he has a |Base*| and wants to do something specific to |Derived*| -- is to ask, "How can I find the _real_ type of the object?" So I would agree that inexperience in OOP usage can be one reason to desire isKindOf(). >> What they do not realize, however, is that C++ programming does not >> always admit of Smalltalk/Objective C/CLOS/etc. strategy. > >C++ strategy *is* Smalltalk/CLOS/Flavors strategy. They have much in common, yes. But static typing is a key difference between C++/Eiffel and Smalltalk/Objective C, because its use (as opposed to its toleration) requires strategies different from from those used in typeless languages. For example, Smalltalk allows the creation of generic |Collection| classes, whereas C++ strongly encourages the use of templates (or low-rent template emulations created with the preprocessor). -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
chip@tct.uucp (Chip Salzenberg) (03/09/91)
According to johnb@searchtech.com (John Baldwin): >Perhaps what we have here is in fact a needed extension to the language >which, when not used judiciously, can be harmful. I would agree, except for the "needed" part. :-/ >Here's the real question: has anyone here needed type testing *for ANY >other reason* than, > 1) to implement persistent objects, or > 2) to allow run-time object selection? I still haven't been shown why type testing is so important for persistent object creation. In other words, as an implementor of persistent objects, what does isKindOf() do for you that virtual functions can't or shouldn't? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
krk@cs.purdue.EDU (Kevin Kuehl) (03/09/91)
In article <503efcc0.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: >IMHO there are many, many more C programmers looking at C++ as a way to reduce >their development and maintenance costs than there are Smalltalk programmers >looking at C++ as a way to turn their protoypes into real products. Although I am quite biased (coming almost completely from a C/UNIX) background, I would agree. Nearly everyone I have spoken to is using C++ as an improvement to their C work. And not just the people here at Purdue, most are just commercial people looking to reduce their maintenance costs. That seems to be the real benefit of C++ IMHO. -- Kevin Kuehl krk@cs.purdue.edu kuehlkr@mentor.cc.purude.edu
ned@pebbles.cad.mcc.com (Ned Nowotny) (03/10/91)
In article <27D7F621.2F5@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
=>According to johnb@searchtech.com (John Baldwin):
=>>Perhaps what we have here is in fact a needed extension to the language
=>>which, when not used judiciously, can be harmful.
=>
=>I would agree, except for the "needed" part. :-/
=>
=>>Here's the real question: has anyone here needed type testing *for ANY
=>>other reason* than,
=>> 1) to implement persistent objects, or
=>> 2) to allow run-time object selection?
=>
=>I still haven't been shown why type testing is so important for
=>persistent object creation. In other words, as an implementor of
=>persistent objects, what does isKindOf() do for you that virtual
=>functions can't or shouldn't?
The problem with persistent objects is not the frequently mentioned
one of knowing which object to construct when a given object is being
read/paged into memory. Any system which supports persistent objects
already solves this problem in one way or another and can solve it
without ever exposing the dynamic type system to the user. (Of course,
this does mean that there is no way to portably store objects of
classes which are provided by a different library than the persistent
object library. However, a consistent dynamic typing mechanism is
only a partial solution. Either persistence should be provided as a
first class facility or you live with the current situation; translate
temporary objects to/from persistent objects.)
The real problem comes up when you only have a base type pointer or
reference to an object that has been retrieved from persistent storage.
Because you no longer know how the object was created (that information
was available in the process which created the object, but not in the
current process without exporting the type mechanism of the persistence
system), you are prevented from using the specialized interface of
derived objects unless you either run that interface back up the
inheritance tree and raise exceptions when the interface is used for
inappropriate objects or you provide some alternative method to get
at an object through a reference or pointer of the appropriately derived
type. However, both of these schemes are essentially equivalent to
providing a mechanism for determining an object's type dynamically,
only more complicated or a violation of the reuse and specialization
concepts of inheritance.
Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX 78720 Ph: (512) 338-3715
ARPA: ned@mcc.com UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.rfg@NCD.COM (Ron Guilmette) (03/10/91)
In article <1991Mar8.024331.14235@searchtech.com> johnb@searchtech.com (John Baldwin) writes:
+
+Here's the real question: has anyone here needed type testing *for ANY
+other reason* than,
+ 1) to implement persistent objects, or
+ 2) to allow run-time object selection?
+
+If not, then maybe what we really need is simply language support for
+persistence. I *know* how painful it is to implement a cohesive and
+consistent object storage utility from scratch! Yes, when it was
+finished, we had something which was (more or less) optimized for
+our particular use, but there was no reason why the language or the
+library could not have provided efficient *standardized* support for this.
[...]
+I guess before I can form an opinion or take a stand, I'd need to know
+which is the actual case: dynamic typing needed directly by the programmer,
+or just better support for persistence??
I think that "persistance" (or more precisely, the ability to get objects
out of one address space and into another reliably) is all that's really
needed. Unfortunately, C++ itself doesn't have any standardized way of
supporting that, nor is it likely to in the forseeable future unless there
can be some concensus among the various groups who have developed solutions
to this important problem. Those groups should first form a concensus
and then present a mutually agreeable proposal to x3j16. Otherwise, all
of the various ad-hoc (and non-protable) schemes will continue to proliferate.
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// New motto: If it ain't broke, try using a bigger hammer.chip@tct.uucp (Chip Salzenberg) (03/12/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27D57565.2B22@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Lots of Smalltalk, Objective C, CLOS, etc. programmers are converting >>to C++, and they are looking for language features like those of their >>previous languages ... > >...people who are already using these other OO languages are already >building reusable code libraries, and there is comparatively less >experience with building such libraries in C++. We might want to >listen to them tell us what they need. I don't know CLOS, but neither Smalltalk nor Objective C include any notion of static type, while static type is one of the fundamental principles of C++. I see no reason to believe that the Smalltalk and Objective C communities see in C++ anything but a pale imitation of the "real" OOPLs they know and love. I, on the other hand, see their total lack of type safety as a fundamental stumbling block for attempts to write reliable software. In a few words: I'll take C++, with static typing and difficult inheritance, over Smalltalk/Objective C, with no static typing but easier inheritance, any day of the week. This chasm of static typing is, IMHO, an insurmountable obstacle for any attempted transfers of reuse techniques between Objective C/Smalltalk and C++. >If the only answer on "how to do it" coming from the C++ community is >"add it as a virtual in the base class". I agree with the author who >called this "laughable". From the perspective of binary-reusable libraries, >anyway. Please remember that "reuse" is not synonymous with "inheritance". >Since C++ is the production language of choice for those building PROTOTYPES >in Smalltalk and CLOS, at least, allowing easy conversion of components >between these languages and C++ is an ongoing problem. If a project will eventually be written in C++, prototyping in Smalltalk is error #1. >I see it happening in dozens of organizations right now... Then they have fallen victim to error #1. :-) >Such opposition appears to be political: you don't want the language >"hijacked" by "outsiders" by which you appear to mean people who aren't >doing everything in C and liking it. I understand why my statements might sound that way. In fact, there's nothing political about my stand. It's a technical issue for me. It's an application of the principle of of information hiding. The C++ type system is capable of choosing among member functions based on dynamic type. Therefore, there is no reason to reveal the dynamic type. The consumer of an object should not be able to discover the exact type of that object; it doesn't have a "need to know." >Prototyping in other OO languages and shipping in C++ is a fact of life. So is COBOL. Who cares? >So is the desire for (and corporate commitment to) extend class hierachies >without source access. At least a lot of firms are planning to waste big >money trying, if waste it is. I look forward to observing the results of such attempts; perhaps I will learn something. But if the only means possible for achieving this goal is the use of isKindOf(), then I consider such projects to be technical failures before they have even begun. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
jimad@microsoft.UUCP (Jim ADCOCK) (03/12/91)
In article <27D572F6.2A70@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: |According to jimad@microsoft.UUCP (Jim ADCOCK): |>...what is really needed is neither the ability to test whether an |>object supports some particular method, nor the ability to test whether |>an object is some exact type, but rather, what is needed is the ability |>to test whether an object supports some particular protocol. | |Even that isn't enough. Two unrelated types can both implement "void |foo(int)". That doesn't mean that the two foos are equivalent. The |"isKindOf" test is the minimum for reasonable dynamic typing in the |C++ type forest. I think you and I have different meanings for "protocol." You seem to use "protocol" to mean the signature of one method. I use "protocol" to mean that an object has to support a *set* of methods correctly matching both in signature and meaning. Thus, I think your call for an "isKindOf" test is the same requirement as I'm calling for.
jimad@microsoft.UUCP (Jim ADCOCK) (03/12/91)
In article <1991Mar7.153417.6489@linus.mitre.org> dsr@mir.mitre.org (Douglas S. Rand) writes: |There is nothing which prevents a programmer from adding type testing |to C++ classes now. Many real programs require some of this. |You can add instance fields which get named in constructors, virtual |functions which return values, all kinds of perfectly acceptable |options are available to the programmer. Yes, one can do this, and many people are. Its just that currently it is ugly and inconvient to do so -- requiring at least some macro hacks. Thus, I say that C++ "enables" but does not "support" type testing. Its not necessary for type-testing to be built into the language in order for C++ to "support" it. The only requirement would be that some way be added to the C++ language to allow people who want to implement one or another type testing schemes to be able to do so cleanly and efficiently. The idea that I propose is that the capabilities of templates be enhanced so that template member function can be specified that are automatically expanded when inheriting from a class with such templated member functions. It seems that there is no way to use templates to accomplish this goal today. Type testing is thus just one example of what seems to me to be a weakness in templates: there seems to be no way to specify templated member functions o that are to be automatically implemented on all derivations. Again a simple example of this is to try to imagine a scheme where a "int SizeOf()" virtual function is to be implemented for all classes derived from some class "O" that needs the "int SizeOf()" method to be correctly implemented in all derived classes. Today, even with templates, the only way to get a correct SizeOf method implemented in each derived class is for the programmer to correctly and manually take some action to implement SizeOf in each derived class. Ugly, and error-prone.
rae@utcs.toronto.edu (Reid Ellis) (03/15/91)
Craig Hubley <craig@gpu.utcs.utoronto.ca> writes: >We might want to listen to [people who are already using other OO >languages and building reusable code libraries] tell us what they >need. Especially if the only answer on "how to do it" coming from >the C++ community is "add it as a virtual in the base class". I >agree with the author who called this "laughable". From the >perspective of binary-reusable libraries, anyway. Why is this "laughable"? This seems to be the crux of the whole thing. Could you expand on this? What's wrong with a class otherType; struct foo { virtual otherType *asOther(); } approach, where "otherType" is a type not defined by the vendor of the [binary-only] class? This allows users to hook their own types in perfectly well. Or doesn't this address the needs you mention? Reid -- Reid Ellis 176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada rae@utcs.toronto.edu || rae%alias@csri.toronto.edu CDA0610@applelink.apple.com || +1 416 446 1644
chip@tct.uucp (Chip Salzenberg) (03/16/91)
According to jimad@microsoft.UUCP (Jim ADCOCK): >I use "protocol" to mean that an object has to support a *set* of methods >correctly matching both in signature and meaning. Thus, I think your call >for an "isKindOf" test is the same requirement as I'm calling for. Apparently. The key thing is that two classes can have identical lists of public member functions, yet be unrelated. So if you find that your "protocol" matches up, that still proves nothing about the ancestry of the object; so that information is useless. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
barmar@think.com (Barry Margolin) (03/20/91)
In article <27E1825C.731F@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Apparently. The key thing is that two classes can have identical >lists of public member functions, yet be unrelated. So if you find >that your "protocol" matches up, that still proves nothing about the >ancestry of the object; so that information is useless. This is true, but it's more likely a problem of namespace pollution than design conflict. If you use a naming convention or other methodology that limits namespace conflicts, then you can be reasonably sure that a member name means the same thing in all classes that publicize it. If you don't use a methodology that limits namespace conflicts then you can't assume that member and overloaded function names always mean what you think they mean, and some errors that could have been caught by the compiler will go unnoticed. Public member and overloaded function names are global resources, and care must be taken with them (just as we have long known to do with global variables). Unfortunately, when using class libraries you are at the mercy of the methodology used by the class implementor. This presumably relates to the thread on namespace issues (which I haven't been reading). This is why Common Lisp has packages; there is no inherent conflict between PACKAGE1:OBJECT and PACKAGE2:OBJECT. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
chip@tct.uucp (Chip Salzenberg) (03/22/91)
According to barmar@think.com (Barry Margolin): >Unfortunately, when using class libraries you are at the mercy of the >[naming style] used by the class implementor. Exactly. That's why a protocol match function would have exactly zero value in portable C++ programming. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
jimad@microsoft.UUCP (Jim ADCOCK) (03/26/91)
In article <27E1825C.731F@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: |>I use "protocol" to mean that an object has to support a *set* of methods |>correctly matching both in signature and meaning. Thus, I think your call |>for an "isKindOf" test is the same requirement as I'm calling for. | |Apparently. The key thing is that two classes can have identical |lists of public member functions, yet be unrelated. So if you find |that your "protocol" matches up, that still proves nothing about the |ancestry of the object; so that information is useless. I would consider that two sets of methods matching in signature but not derived from the same parent are not matching in "meaning". Thus my concept of "protocol matching" implies that the methods found in the two matching protocols derive from a common parent, thus implying ancestry.