Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!linus!linus!mir!dsr From: dsr@mir.mitre.org (Douglas S. Rand) Newsgroups: comp.lang.c++ Subject: Re: asking an object for its type Message-ID: <1991Mar8.174723.19540@linus.mitre.org> Date: 8 Mar 91 17:47:23 GMT References: <71037@microsoft.UUCP> <27D57565.2B22@tct.uucp> <1991Mar8.024331.14235@searchtech.com> Sender: news@linus.mitre.org (News Service) Reply-To: dsr@mir.mitre.org (Douglas S. Rand) Organization: The MITRE Corporation Lines: 38 Nntp-Posting-Host: mir.mitre.org 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: Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ