🚀 go-pugleaf

In <4d31ne$2m6@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
>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,

As I said, the problem comes only when they believe the promise that the
HN prefix makes. If you're going to ignore that promise on all variables,
why bother making it in the first place? Absent the HN prefix, anyone
looking at the code will automatically look back to the declaration to
find the type, and my automatic reflex when I see a pointer or reference
type in C++ is to check the class heirarchy. If I believe the HN prefix,
I don't have a reason to check the declaration, I won't see the reference
typing, and I won't get reminded to check the heirarchy before assuming
that it's really the type claimed. Pointers are more obvious, but HN is
still making a promise that a pointer to Stall is a pointer to Stall and
not a pointer to OfflineStall so the potential for believing the promise
is still there.

Leaving the HN off won't guarantee the programmer will check, but at least
it doesn't give him an excuse to cry "But the name *said* it wasn't an
OfflineStall!". It's the same as with misleading comments. The idea of a
comment is to tell you what the code is supposed to be doing without first
having to decipher it in detail. If you have to assume the comments are
wrong and decipher the code in detail anyway, are the comments really
doing any good?

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

That is in fact the case. The Stall class defines the interface and certain
"normal" behavior, and each subclass alters some portions of that behavior
as needed. The problem comes when someone else comes along to do maintenance
on the code. They know what they want to have happen, the question is what
part of the code do they need to change to make it happen. If they read the
detailed design and roadmap document they'll be fine no matter what, but
if they begin by tracing the code to see where the action they want to
change gets triggered ( easy enough, it's a very straight line to the one
member function that handles that action ) then they'll find at that point
that they are dealing with a reference to a Stall. If they have a reason to
believe that, they would then obviously find that member function in the
Stall class and modify it, neglecting to check the class heirarchy to see
whether at that point that reference could be to some other derived class.

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

No, every service can be defined in some sensible way for the base class.
Each subclass then alters some or all the behavior of some services to be
appropriate to the particular type. In some cases the subclass must alter
one part of the service for the whole to make sense, but each subclass
alters a different part. For instance, if a particular subclass has to
answer "Yes" to one or more of three questions, the base class answers
"No" to all three and the subclasses only replace the one or ones that they
need to answer "Yes" to.

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

I dislike using RTTI for that. It smacks too much of type fields, and I
generally don't need to know the type in the code that uses them. It's
the guy who has to figure out where a change needs to be made, and in
which class, that needs to know.

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

This speaks to use only. To use a class you only need to know the interface.
However, suppose you have a List class that provides the interface and
subclasses ArrayList and LinkedList that provide the implementation. You
can use them without knowing which one you're dealing with readily enough.
But, if one of them is causing segmentation violations, whoever has to go
in and find and fix the bug bloody well has to know which *exact* class
was being used at the time. If the segv occurred when comparing two Lists,
he needs to know that it was two ArrayLists being compared via references
to the base class or he may wind up trying to fix code that does not contain
any bugs ( a rather frustrating excercise in futility ).

--
Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
                                      |  Member, USENET Cabal

Seriously, I don't want to die just yet.  I don't care how
good-looking they are, I! don't! want! to! die!"
                                        -- Megazone ( UF1 )