🚀 go-pugleaf

According to dsouza@optima.cad.mcc.com (Desmond Dsouza):
>... only requires that (x.class) be of type, say, "ClassId", which
>supports "ClassId == ClassId" for class identity, and possibly
>"ClassId <= ClassId" for sub-class checks. ... It does not require
>a unique program-wide integer per class.

I stand corrected.

>It is reasonable for x.class to be a virtual function call ONLY if
>class X already has virtual functions ... Hence, you do not have to
>add virtual-ness to otherwise non-virtual classes.

I stand corrected^2.  It wouldn't be the efficiency hog I had claimed.

Nevertheless, I have a hard time supporting the feature.  Every time I
hear "typeof(foo)" I see masses of poorly-written Smalltalk: "foo
isTypeOf: OrderedCollection or: foo isTypeOf: UnorderedCollection..."

>Here are a few examples where you need to know the type of an object:

"Need?"  That's a red flag for me... :-)

>1. Persistent objects: When reading in one of these from disk, you
>   need to know what constructor to call. Hence you need to encode in
>   the persistent image the ClassId of the object.

Presumably, a well-designed class hierarchy will use a virtual
function to store objects; and a virtual function by definition will
already know the exact type of the object it is storing.

>2. You have an interactive system where a mouse-weilding user
>   dynamically configures objects together. You need to check the
>   configuration for validity ...

ClassID would be a useful tool in such code, but it is by no means
necessary.  For example, each class can have virtual functions along
the lines of "int can_be_owned()".  And do you want J. Random Coder
making decisions like "if x is a Widget, but not a FooWidget..."

>3. Almost any application related to a programming environment:
>   debuggers, smart re-compilers, ...

I can see it for debugging.  But the extra cost of the feature is not
something I'd want to inherit permanently in my delivered executable.
And I must say that debugging alone is a little thin as justification
for a language feature with run-time costs.

>C++ cast restrictions on virtual-base classes (cannot cast from
>virtual base to derived) could be removed if the compiler made some
>of this information available at run-time!

But you can always write a virtual function that does the cast.
-- 
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)