Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

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

Robert Dewar wrote:
> 
> John suggests
> 
> <<        Uint : Uint_Type;>>
> 
> UGH! No, I don't like that at all. Why choose a name for an object that
> emphasizes the type of the object. I choose my object names to emphasize
> the use of the variable at a higher level of abstraction.
>
> Suppose I have a universal integer value that is the size of operand 1.
> Then I would never write the above line, instead I would write:
> 
>     Opnd1_Size : Uint;

I see the misunderstanding now.  I thought you were talking about the
case where you were dealing with "universal integer" as the syntactic
element currently being compiled, similar to "statement", "expression",
etc.  If that were the case, then in fact "universal integer" would _be_
the abstraction, and my suggestion would be appropriate.

But here it seems you are just dealing with a data component of some
other abstraction, and that component happened to be implemented using
your internal representation for a universal integer.

In that case, I wonder why expose the particular implementation of that
value?  It could be that a later design change results in that value
being implemented differently.  How about:

    Operand_1_Size : Operand_Size_Type;

or better:

    type Operand_Type is ...
      record
        ...
        Size : Operand_Size_Type;
        ...
      end record;
    ...
    Operand_1 : Operand_Type; -- now can reference Operand_1.Size


Operand_Size_Type might be derived from Uint, or it might just be a
subtype of Uint, or it might (long shot) be a private type that hides a
Uint, or... ah, but I see this opens up a whole other can of worms. 
It's the old apples and oranges question, and what's an apple versus an
orange, and when do you really need distinct types?  I won't try to
argue the exact design decision you made here...

Yes, if you decide to give one implementation type such broad usage
without distinguishing different usages as distinct types/subtypes, then
of course the variable names should not reflect the implementation.

> Similarly, I cannot imagine calling a variable Integer, so where you
> suggest
> 
>     Integer : Integer_Type;
> 
> I would far prefer to write:
> 
>     Number_Of_Attempts : Integer;

Isn't it bad form to over-use the standard integer types?  Again, the
apples and oranges question.  In this case, I might have done:

   type Try_Count_Type is range 0 .. Try_Limit;
   -- Try_Limit might change, changing the implementation needed.
   -- Also, want to distinguish this from e.g. Error_Ident_Type.

   Try_Count : Try_Count_Type;

> I have *never* wanted to call a variable Integer, and that is why in this
> case Integer is the right name for the type.

The cases I had in mind where you might want to do this are in defining
the abstraction for "integer" itself, e.g.:

    function "-" (Integer : in Integer_Type) return Integer_Type;

    function Integer_Type'Succ (Integer : in Integer_Type)
      return Integer_Type;

similarly:

    function "not" (Boolean : in Boolean_Type) return Boolean_Type;

    function Float_Type'Ceiling (Float : in Float_Type)
      return Float_Type;

I can see this is a bit of a stretch: Is the real abstraction here the
type being manipulated, or the functions themselves? I.e., is it more
important in this case to emphasize which data abstraction the parameter
implements, or is it more important to emphasize the role the parameter
plays within the function, actually re-using the same role names across
all the overloadings of the function?  E.g., our current situation:

  function "<" (Left, Right : Integer) return Boolean;
  function "<" (Left, Right : Float)   return Boolean;
  function "<" (Left, Right : String)  return Boolean;
  ...

versus the hypothetical:

  function "<" (Integer, Than_Integer : Integer_Type) return Boolean;
  function "<" (Float,   Than_Float   : Float_Type)   return Boolean;
  function "<" (String,  Than_String  : String_Type)  return Boolean;

The fundamental question here is, when we deal with the built-in types
and their operations, are we dealing with purely functional
abstractions, or can we view these types as data abstractions comparable
to typical abstract data types (Set, List, Queue, etc.)?

If the latter, my naming convention can be made to fit them. If the
former, my scheme is inapplicable.

> On the other hand, there are cases where there is little separation between
> the abstraction levels of the type and its use, e.g. when you have an
> enumeration type where there is only one instance of the type, as in
> 
>    type System_Status_Type is (Going, Stopped, Terminating, Starting);
>    System_Status : System_Status_Type;
> 
> in this case, a standard suffix is appropriate, and I favor using _Type
> as the suffix in a case like this.

Glad to see you agree... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------