🚀 go-pugleaf

(Thomas Wang) writes:

>Suppose we have an 'array' library that always operates on objects of
>class 'object'.  Now suppose you have a class called 'person'.  You
>put some 'person' objects into an array variable.  A problem that will
>come up when one tries to retrive the objects out of the array.
>A 'person*' that was put into the array will come out as 'object*'.
>Is it safe to cast from 'object*' to 'person*'?  Conceptually speaking,
>it is safe to do the casting iff the object isa 'person*'. (note 1)
>This question cannot be answered without knowing some run-time typing
>information.  Assuming you can do the cast, then you can call member
>functions of 'person', such as ((person*) obj)->walk().

This may be a silly question but since storing a pointer to an object can
lead to that object changing after being installed in an array, would it
not be better to actually store the object. Making a generic array class
which is pointer based is an object abuse waiting to happen. For example
I might declare a single 'person' object iteratively fill it from some
database, installing each copy in the array. I would expect that I was making
an array of objects and not an array pointers, so I would expect an array
of unique object, but get an array where only one object is referenced.

My point is that in terms of the design of a "generic" array class the
pointer implementation makes it too easy for someone else using the class
to use it wrongly. Templates seem like the ideal solution when you have an
array of class objects.

>The designer of the 'object' class have no way to know there will be a 'person'
>class later, so defining walk() function as base virtual from the 'object'
>class is really not a solution.

>So far, the only good use of type information I have found is the example
>above.  Seems in all other cases, virtual functions can serve better than
>explicitly looking at runtime typing information.

It seems to me that situations where you need to know type information at
run time are the exception and not the norm. That being the case would it
not make more sense to only encode type information when you may need to
know an objects type and do this by making a class that has type information
and a union of all possible object types? In any event it seems to me that
some special case handling of the need for dynamic type information can be
when needed as the need does not arise frequently and workaraounds are usualy
available to the enterprising programmer. In other words when I find an
detail of a programs structure gets sticky, I usualy find another way to
structure the program, preferable one that is less sticky.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com