Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney <matthew_heaney@acm.org>]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> Look, I provided you with one puzzle to solve, but you insist on solving
> a different one, one that's easier for you to fit into your scheme. 
> Okay, fine, but how about solving my puzzle, too?  What if  -- what if
> -- you were presented with a problem domain where there are cars, and
> there are colors, and there are other things that can have colors, and
> any car can get any of the colors?  For me, if I were coding in Ada, it
> would be simple:

I don't accept your argument, because I don't accept your premise.

I can only speak from my own experience.  And from my own experience,
color types, and speed types, and heading types, don't exist
independently of higher level abstractions, like cars, and targets, and
airframes, and ownships, etc.

If you have a compelling need to declare an enumerated color type (say),
for use by multiple abstractions, then go ahead and name it Color_Type:

package Color_Types is

   type Color_Type is (...);

end Color_Types;

My philosophy is to use the name _Type only as a last resort, as it has
a sort of generic quality to it.  That sometimes turns out to be useful,
as in the example above.  Some guys name generic formal types _Type, for
exactly that reason.

But if I'm implementing a car abstraction that had a color attribute,
then I would name the color type Car_Color.

You point out a problem with this scheme, and that is if there are two
color objects in the same scope.  You correctly observed that my use of
an abbreviation in that case wouldn't be necessary if I had used the
name _Type.