Re: Naming of Tagged Types and Associated Packages

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

Tucker Taft wrote:
> 
> A better choice for object names is often something that indicates
> the specific role the object plays, rather than a name that simply echos
> its type name.  
...
> Prepositions like "From" or "To", qualifiers like "Source" and "Target"
> or "Next" and "Prev", etc., often are better than just names that
> parrot the type.
> 
> Remember that every name is a chance to communicate something of
> interest to the reader.  Make every name count (sounds like bidding
> in the game of "Bridge" -- "make every bid count").

Yes, role names (particularly role names on logical associations a la
UML) are a fertile source of variable names (especially names for object
attributes -- record components, in Ada terms).  When an analysis of the
problem domain provides such names, they should of course be used to
advantage. 

Borrowing an Eiffel example from OOSC2 (Meyer):

    class PERSON feature
        ...
        spouse: PERSON
        landlord: PERSON
        ...
    end

and adapting it to Ada:

    type Person_Type is ... tagged ... private;
    type Person_Access_Type is access all Person_Type'Class;
    ...
    type Person_Type is ... tagged 
      record
        ...
        Spouse   : Person_Access_Type;
        Landlord : Person_Access_Type;
        ...
      end record;

we can see that, in this case, the attribute names do not need to
"parrot" the type name. 

However, many times the most appropriate role name turns out to be
exactly the same term used for the type name itself, and so the
type/object name-clash reasserts itself.  

For instance, going back to our (now quite moldy) example of the "color"
of a "car", here in Eiffel:

    class CAR feature
        ...
        color: COLOR
        ...
    end

    ... -- Usage:
        car: CAR
        ... car.color ...
        
and here in Ada: 

    type Car_Type is ...
      record
        Color : Color_Type;
      end record;

    ... -- Usage:
        Car : Car_Type;
        ... Car.Color ...
 
The attribute in this case is an instance of the "color" type.  It plays
the role of being the "color" of a "car".  Calling it anything else
("paintjob"?) :-) would seem contrived.

> Presumably there is more than one object of a given
> type in existence.  

In "existence", perhaps, but not necessarily in a given scope ...

> The names ought to distinguish these objects by
> hinting to the reader what they are used for.  

This is true when these objects are in a scope where their
distinguishing roles need to be highlighted.  But in building the
abstractions for our types, we often encounter objects in contexts where
any specific role has been abstracted away:

    package Persons is

      type Person_Type is ...

      function Get_Name (Person : in Person_Type) return String;
      ...
    end Persons;

What other "role" is the person in the Get_Name function playing, other
than simply being the person whose name we wish to retrieve?  Yes, we
know that some actual parameters passed into this formal parameter may
turn out to play specific roles such as "spouse" or "landlord" or
"employee", but that is irrelevant at this level of abstraction. 

> For example,
> an object of type  "Speed_In_Knots" is presumably the speed for
> some particular other entity.  Presuming that that other entity has
> a meaningful name, then its speed might be named "<entity>_Speed".

Are you suggesting this sort of redundancy:

    type Car is ...
      record
        ...
        Car_Color : Color;
        Car_Speed : Speed_In_Knots;
        ...
      end record;

    ... -- Usage:
        Some_Car : Car;
        ... Some_Car.Car_Color ... 
        ... Some_Car.Car_Speed ...
                 ^^^^^^^  
-- 
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