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

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

W. Wesley Groleau (Wes) wrote:
> 
> John G. Volan wrote:
> >
> > Jeff Carter wrote:
> >
> > > The problem with putting _Type on the end of all [sub]type names is that
> > > it adds no information.
> >
> > But that's the whole point! Adding any more information is _undesirable_
> > at this point, because presumably an object and its type _both_
> > represent the _same_ concept
> 
> If
>    Angle : Angle_Type;
> is the only object of Angle_Type, 

Nope, that's a nice strawman, but that's not my position at all, you're
reading that into what I said.  "Angle" is not necessarily the only
Angle_Type object _in the program_, but it may be the only Angle_Type
object _in a given local scope_.  In that local context, why should I be
forced to call that object anything other than the simple word "Angle"?

> then perhaps the declaration of
> Angle_Type is just clutter.  (See my recent post about anonymous
> array types.)  But "Angle" is rather vague.  Might we in the future
> want to deal with more than one Angle?
>
> The "same concept" argument could be interpreted to recommend:
> 
>    Angle_1   : Angle_1_Type;
>    Angle_2   : Angle_2_Type;
>    Sum_Angle : Sum_Angle_Type;
> .....
>    Sum_Angle := Sum_Angle_Type (Angle_1) + Sum_Angle_Type (Angle_2);

Again, quite a pretty strawman. (I can't believe you are being serious
here.)  Of course you can have as many Angle_Type objects as you like,
prefixing (or even suffixing) the "Angle" word with whatever "specific"
modifiers you like, e.g., 

   Start_Angle, End_Angle, Rotation_Angle : Angle_Type;
   ...
   End_Angle := Start_Angle + Rotation_Angle;

or perhaps:

   procedure Rotate
     (Angle          : in out Angle_Type;
      Rotation_Angle : in     Angle_Type)
   is
   begin
     Angle := Angle + Rotation_Angle;
   end Rotate;

My scheme has the advantage that a "specific" identifier such as
"Start_Angle" is clearly the name of an object, and can never be
confused as the name of a "specific" derived- or sub-type of Angle_Type.
A subtype or derived type would always be marked "_Type" just like any
other type:

  type Angle_Type is digits ... ;
  -- for angular values in general (in degrees)

  subtype Proper_Angle_Type is
    Angle_Type range 0.0 .. Angle_Type'Pred(360.0);
    -- for angular values constrained to non-negatives
    -- within one cycle

  subtype Signed_Angle_Type is
    Angle_Type range -180.0 .. Angle_Type'Pred(+180.0);

  type Direction_Type is new Proper_Angle_Type;
  -- for navigational compass-directions

  type Longitude_Type is new Signed_Angle_Type;
  -- for geographic longitudes

> If "adding any more information is _undesirable_" then I would say
> that a language construct that _must_ be there (though it adds nothing)
> is either a flaw in the language or (more likely) a sign that the
> program still needs some abstract thought.

Go back a couple posts and look again.  I was objecting to Jeff Carter's
suggestion of a whole smorgasbord of different type-marking suffixes for
the different classes of types. For example, for a floating point type,
you might have something like (not one of Jeff's examples but similar):

  type Angle_Real is digits ...;
  -- "Real" marks it as a floating point type

  Angle : Angle_Real;

I say, why encode such an implementation detail into the type name and
not inro the object name, too?  You should either encode it in both or
in neither (and I strongly favor encoding it in neither!)

> The above snippet is much clearer as
> 
>    Start_Point, Rotation, End_Point : Angle;
> .....
>    End_Point := Start_Point + Rotation;

The synonym scheme again.  This blithe violation of semantic economy
will cost you later if you decide to use the word "Point" to refer to a
two-dimensional cartesian-coordinate vector, and use "Rotation" to refer
to a rotational transformation matrix.  It may be wiser to be thrifty
with your semantics from the start, and simply retain the word "Angle"
in your objects of Angle_Type:

  Start_Angle, Rotation_Angle, End_Angle : Angle_Type;
  ...
  End_Angle := Start_Angle + Rotation_Angle;
  ...

  function Get_Rotation
    (Angle : in Angle_Type)
     return Rotation_Type;
     -- generates coordinate transformation matrix to rotate 
     -- points around the origin by the given angle

  function "*"
    (Rotation : in Rotation_Type;
     Point    : in Point_Type)
     return Point_Type;
     -- applies rotational transformation matrix to point

  ...
  Start_Point, End_Point : Point_Type;
  Rotation : constant Rotation_Type :=
    Get_Rotation (Angle => Rotation_Angle);
  ...
  End_Point := Rotation * Start_Point;

------------------------------------------------------------------------
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? :-) ");
------------------------------------------------------------------------