🚀 go-pugleaf

According to dsouza@optima.cad.mcc.com (Desmond Dsouza):
>Retrieving and re-constructing persistent objects is where you *need*
>explicit type information.  Virtual functions dont help now ...

Of course they don't help; but explicit type information doesn't help,
either.  The language type system is inoperative when dealing with
objects that have been "frozen" into dead arrays of bytes.

>Storing objects is relatively easy, e.g. with a virtual function which
>writes out some ClassId information.  Hence, your objects must have a
>way to access (and write out) their true type.

When a virtual function is invoked, the type is implied, unless the
programmer has made the mistake of allowing a virtual function to be
inherited by a derived class that should be frozen in a distinct way
from its parent.

>Solutions like "virtual int can_be_owned()" are an incredible
>implementation overhead when you are dealing with combinations of
>object classes and relationships between them. 
>
>e.g. Can an A be plugged into a B in the slot x ? How about an A1 into
>slot z of a B1?

The problem as described is inherently complex.  The complexity of a
solution is neither created nor worsened by a solution of the
can_be_owned() type.

>Why not offer the type checking facility and teach J. Random Coder
>when _not_ to use it ?

I agree with this approach.  After all, if I opposed features purely
on the basis of possible misuse, then I wouldn't be using C++.  :-)

So in the end, my opposition isn't to the feature, but to the attitude
manifested by some that it's practically necessary for OOP.  It's not.

``isKindOf is the OOP equivalent of goto.''  --me

>Consider the proposed (now accepted) Exception Handling scheme for
>C++. The statement:
>  catch (ErrorClass& o) {
>	....
>  }
>is supposed to 'catch' a deeply nested call to:
>  throw ErrorClass("someError");

Unless I misunderstand the implementation issues, name equivalence can
solve this problem without resorting to dynamic type information, and
also without incurring run-time overhead that dynamic type checking
would likely impose.

> > But you can always write a virtual function that does the cast.
>
>True. It is painful, error-prone, and the compiler can do a much better job.

My experience is not so negative, though I grant that I'd prefer the
compiler to more of my work.  (Always!)
-- 
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)