Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!cline From: cline@cheetah.ece.clarkson.edu (Marshall Cline) Newsgroups: comp.lang.c++ Subject: Why ask an object its type?? (was: libraries, compilers, class...) Message-ID: Date: 4 Oct 90 18:19:42 GMT References: <995@halley.UUCP> <57751@microsoft.UUCP> Sender: news@news.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY Lines: 73 In-Reply-To: bobatk@microsoft.UUCP's message of 26 Sep 90 15:15:50 GMT Nntp-Posting-Host: cheetah.ece.clarkson.edu In article <57751@microsoft.UUCP> bobatk@microsoft.UUCP (Bob ATKINSON) writes: >Marshall Cline writes: >>In article <995@halley.UUCP> kelley@halley.UUCP (Michael Kelley) writes: >>>What are your views on an appropriate name for a run-time function to return >>>class information? >>Runtime (weak) typing is wonderful if you want a toy language that will >>solve toy problems. Strong typing is nearly essential for programming in >>the large. >Static typing is *orthognal* to being able to query an object to learn about >some of the characteristics of its type, which is often done by returning >a class-related object. It is a perfectly reasonable thought to consider >adding a member fn to C++ objects, say, to return such a CRO. > Bob Atkinson > Microsoft I expected to get lots of exciting commentary from the above statements. But I didn't expect this one. Yes, in a sense, the *ability* to find out the dynamic type of a referred object is orthogonal to strong typing. However the *use* of such a construct may (and probably does) indicate a weakly typed program. I'd like to ask a key question: ``WHY ASK AN OBJECT ITS TYPE?'' There are several answers that I can think of, and presumably others will add some more. [1] you might ask an object its type to determine if a particular message is applicable. This is one of the worst possible (mis)uses of the CRO concept, since it is the antithesis of strong typing. [2] you might ask an object its type so you can do a safe down-cast. This often amounts to the same thing as [1], since if both the static type of the reference and the dynamic type of the object have the desired member function, then the (strongly typed) virtual mechanism is preferred. [3] if you're reading an object from persistent store (or from a network wire, etc), you absolutely need to ask it its type since there is no way for a compiler to statically determine its type. Of the answers I gave (and I emphasize that others will think of more), the only one where we really *need* weak typing is persistent objects. From discussions with others about this issue at C++-At-Work last week, C++ seems to be headed towards treating persistence as a *language* issue rather than as a library issue. Ie: handing the users with a ``CRO'' would tempt them to ``switch on the object type,'' which will lead to hopelessly bad code. If instead case [3] is treated at the language level, we might achieve many of the advantages of a ``CRO'' without the disadvantages. Marshall Cline PS: here's another possible reason to ask an object its type: [4] another respondent indicated that it's easier to compile weakly typed OOPLs and hot linking is easier, since all of the type resolution is pushed off until runtime. Is compilation of C++ ``too'' difficult? Probably yes :-), but that's why compiler writers get paid so much! Seriously, making the language easier to compile is nice, however the type checking mechanism is rather straightforward. Existence proof: Turbo-C++ compiles C++ code only about 30% slower than TC compiled typical C code (whatever `typical' means! :-). -- PS: If your company is interested in on-site C++/OOD training, drop me a line! PPS: Career search in progress; ECE faculty; research oriented; will send vita. -- Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600