🚀 go-pugleaf

Todd Knarr (tknarr@xmission.com) wrote:
: Except that, if you tell people that the prefix on the name tells the
: type of the variable, they may believe you. If they do, in the case
: of my example, they might well say "Oh, the prefix says that's a Stall."
: and merrily proceed to locate the Stall class and begin working with
: it. If they are not intimately familiar with the design of my code
: ( which they may not be, work assignments tend to be handed out based
: on who is available rather than who is most familiar with a given bit
: of code ), they may assume they can trust the prefix to be right and
: skip checking the prototype, the class heirarchy and the like and go
: right to the class that the variable *says* it is rather than finding
: out what it *really* can be. The end result will be, at the very best,
: a simple failure of their changes to work. At worst they'll have a
: 16 megabyte core dump on their hands.

It is funny to me that you used references in your example rather than 
pointers.  The problem is equivalent and intrinsic to the nature of 
polymorphism: a reference or pointer can stand for not only a object of
the same type, but of all derived types as well.

Funny enough, even in the absence of HN it seems that there would still
be a problem.  Someone would look at the declaration of the reference
and see that "ambiguous" type and could very well be decieved.  Frankly,
I don't see how this deceit that you want to prevent is any more 
compounded if the programmer gleans the type from a HN prefix or the 
variable declaration.  If they don't look at the class hierarchy they
may be screwed nonetheless, by you reasoning.  Personally, I think that 
there are good reasons why this shouldn't happen, but I'll get to them
in a little while.
 
: >Why never a Stall?  If Stall's interface is present in any of its derived
: >classes, Stall calls should be resolved.
: 
: Simple: Stall is merely the base class, and objects of it are *only* created
: during program initialization as a bookkeeping device to keep track of
: information while the program determines the actual current status of the
: shower stall the Stall object represents.
: 
: Once you get into the subclasses, you get serious behavior differences.
: For instance, Stall objects do not respond to changes in the physical stall
: they represent. The routines are there, but they merely return. Each
: subclass implements different behavior to a different set of changes, as
: appropriate.

I don't really get the problem.  If your derived Stalls are true 
specializations of the Stall concept, then there are certain operations 
which apply to all Stalls and there are operations which apply only to
specific classes of stalls.  The former should be in the base Stall class
and the latter in each of the derived classes.  If inheritance is used this
way, then any place you have a Stall pointer or reference you should be
performing a valid operation.  If this isn't the case, one could argue 
that the use of inheritance is suspicious.

I may be wrong, but do you have services in your base Stall class which 
would more appropriately be in a derived Stall class only?

There is alway RTTI.  You could query and then downcast, but I've never
had to do that in practice.

Truly, however, HN can work with polymorphism as long as the assumptions 
of polymorphism aren't broken, and the prime assumption is that the methods
available for base classes have reasonable behavior for all derived classes
if you choose to pass around base class pointers and references.

-Mike