Newsgroups: comp.lang.c++
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: asking an object for its type
Message-ID: <1991Mar19.171642.19551@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <27D572F6.2A70@tct.uucp> <71199@microsoft.UUCP> <27E1825C.731F@tct.uucp>
Date: Tue, 19 Mar 91 17:16:42 GMT

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