🚀 go-pugleaf

In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:

	>   >Here are a few examples where you need to know the type of an object:
	>
	>   "Need?"  That's a red flag for me... :-)

It is a red flag for me too. And lots of red flags mean it is quite
possibly a legitimate shortcoming.

	>   >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.

Yes, but it needs to make it _explicitly_ available in the binary image.

Retrieving and re-constructing persistent objects is where you *need*
explicit type information.  Virtual functions dont help now because
you do not have an existing object to dispatch off.  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.

Ditto for transferring objects across address spaces, networks, etc.

	>   >2. You have an interactive system where a mouse-wielding 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..."

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?

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

	>   >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.

The cost, as you admitted, can be quite manageable. The primary
problem, as Stroustrup points out, is pick an acceptable amount of
functionality for 'ClassId'.

Check out some papers on "reflection" in languages to see just how
powerful classes-as-objects _can_ be. In fact, persistence, dynamic
configuration and debugging can be all viewed as "reflective"
capabilities. 

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");

Any implementation of this involves a run-time type check, including
class derivation, on the object being thrown. Can you say 'Meta-class'?

Most static class variables and static class functions (explicit or
implicit) can be considered members of a corresponding class object.

	>   >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.

True. It is painful, error-prone, and the compiler can do a much better job.

	>   Chip Salzenberg at Teltronics/TCT      <chip@tct.uucp>, <uunet!pdn!tct!chip>

Desmond.
--

-------------------------------------------------------------------------------
 Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324
 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza