🚀 go-pugleaf

According to craig@gpu.utcs.utoronto.ca (Craig Hubley):
>PROBLEM accessing features that do not exist on all of the possible types of
>	a passed object, e.g. "is this a circle of diameter > 30 ?"
>
>TODAY	explicit type tag
>	- inconsistent across user programs
>	- cannot be added to imported classes

Bzzt.  You forgot:

TODAY.2 virtual member function that does the operation or reports
        failure and/or raises an exception.
	- uses language features already available
	- doesn't require client changes when class hierarchy changes

>SOL.2	.class member, similar to .this member

This solution would require a unique program-wide integer that would
represent each class.  (Can you say Objective-C?  Ugh.)  It would also
impose the space overhead of virtual functions on classes that do not
need it.  It would further make programs dependendent on the details
of inheritance.  ("Let's see, I want all subclasses of foo except bar,
um, they're larry, moe, curly..."  Double ugh.)

>SOL.3	conditional cast, similar to catch

Eliminates the knowledge-of-inheritance problem, but cost-of-virtual
and unique-class-id problems are still there.

>SOL.4	as above, only testing for presence of members, not name of classes

How do you know that "circle.size()" and "building.size()" are in any
way related to each other?  You don't.  Member name is meaningless
without some indication of which "size()" is the Right One.  So once
you figure out which one is the Right One, make it virtual.  Presto.

>It just isn't a controversy, except for Bjarne it seems.  At least I
>haven't seen any evidence of someone else saying you should never see
>the type of an object.

Count me in with Bjarne.  You, the programmer, never really want to
know the type.  You may think you want to know the type, but why?  So
you can know if a feature is available.  So make the feature a virtual
function and be done with it.

>I hope ANSI C++ doesn't end up as a half-baked collision of object-oriented
>dogma and C dogma.

Why change now?  :-)

>The mere fact that compiler developers are including it is a strong
>sign of user demand, and it is obviously not ignorant demand.

"Obviously?"  It's not obvious to me.

>There are such things as optimizing compilers, which C-heads usually have
>never heard of because the language's low-level constructs are so pervasive
>and hard to optimize.

I know all about optimizers, thank you very much.  They are utterly
irrelevant to the issues of type knowledge.
-- 
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)