Re: Naming of Tagged Types and Associated Packages

["John G. Volan" <johnvolan@sprintmail.com>]

Matthew Heaney wrote:
> 
> "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.

Alright then, if "secondary" abstractions just keep distracting you from
my point, forget about the secondary abstractions.  What about the
primary abstractions themselves?  My point is about primary abstractions
anyway.  

It may be comforting to you to keep focusing on secondary abstractions,
because your naming scheme works so well for them: The primary
abstractions they are attached to are such a convenient source for the
expendable prefix you need.  But where do you get an expendable prefix
for a primary abstraction?  I was trying to get you to see that your
scheme was ad-hoc, because there really is no general source of
expendable prefixes for primary abstractions.

To demonstrate the dilemma, I was hoping, for the sake of example, that
you'd be able to treat the notion of "color" as a primary abstraction (I
even sketched how it might look as a private type), but for some reason
you seem stuck on "color" being just a secondary abstraction
(implemented as a scalar type).  If it will help, try a different example:

    with Patients; use Patients;
    package Doctors is

      type Doctor_Type is ... private;

      procedure Treat_Patient
        (Doctor  : in out Doctor_Type;
         Patient : in out Patient_Type);

      procedure Bill_Patient
        (Doctor  : in out Doctor_Type;
         Patient : in out Patient_Type);
      ...
    end Doctors;

Here, the problem-domain concepts of "doctor" and "patient" are treated
as primary abstractions, each implemented as a private type encapsulated
in a separate package.  Cohen naming style has been systematically
applied: From the problem-domain terminology of "doctor" and "patient",
the package names have been derived by taking the plurals, and the type
names have been derived by appending "_Type".  This leaves the simple
form of the terms free to use as nondescript instance names, such as the
formal parameters of procedures like Treat_Patient and Bill_Patient.

Starting from the same problem domain concepts, "doctor" and "patient",
what names would your technique generate for the packages, the types,
and the nondescript formal parameters? 

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

See above, and see my previous post: I had Color_Type as private type,
not just an enumerated type.  It had operations allowing a color to be
formed from percentages of red, green, and blue components.  That's a
significant enough abstraction to warrant its own package, and you
wouldn't want to repeat all that code in client packages like "Cars".

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

No, the example was two different _types_ used in the same context:
File_Mode and Operational_Mode; which, after jettisoning their
"expendable" prefixes, yield the same variable name: Mode.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE