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

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

Do-While Jones wrote:
> 
> Speaking from a maintenance point-of-view, I certainly prefer
> 
>   package Angles is
> 
>     type Degrees is digits ...;

Do-While, you're running the risk here of resurrecting another
unkillable thread... :-)  My emphasis has been that if you have a clear
abstraction (=concept=object class) then naming should just fall out of
that.  People have been side-tracking this point by moving the
abstraction boundaries around. If I answer this, I run the risk of yet
another tangent.

Oh, well, here goes anyway:

What if the units are an implementation detail that you want to hide? 
What if you decide later that, for efficiency reasons, all Angles are
best implemented in radians rather than degrees?  Then your suggestion
would lie closer to the Hungarian end of the naming spectrum: encoding
implementation details in the name.

  with Unitless;
  package Angles is

    type Angle_Type is private;
    -- Going with a private type is a tough decision here.
    -- I'm not necessarily recommending it.  An alternative
    -- could be to make this a visible float type and just
    -- override as abstract any built-in functions (e.g. "*")
    -- that violate unit dimensionality. But as an academic
    -- exercise, let's see where this leads us ...

    function "*"
      (Left  : Unitless.Quantity_Type;
       Right : Angle_Type)
       return Angle_Type;

    function "*"
      (Left  : Angle_Type;
       Right : Unitless.Quantity_Type)
       return Angle_Type;

    function "/"
      (Left  : Angle_Type;
       Right : Angle_Type)
       return Unitless.Quantity_Type;

    ... -- etc.

    -- the following are functions rather than constants
    -- in order to make them inheritable

    function Zero return Angle_Type;

    function Degree return Angle_Type;

    function Radian return Angle_Type;

    function Cycle return Angle_Type;
    -- = 360.0*Degree = 2.0*Pi*Radian

    function Hemicycle return Angle_Type;
    -- = 180.0*Degree = Pi*Radian

    function Quadrant return Angle_Type;
    -- = 90.0*Degree = 0.5*Pi*Radian

    ... etc.

    function Get_Complement     -- = Quadrant - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Supplement     -- = Hemicycle - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Proper_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Proper_Angle_Type;

    function Get_Signed_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Signed_Angle_Type;

    ... -- etc.
  end Angles;
 
> Never express in a comment that which can be expressed in the code.
> 
>   DIRECTION : Angles.Degrees;
> 
> is safer than
> 
>   DIRECTION : Angles.Angle_Type; -- in degrees

Or perhaps:

  with Angles;
  package Directions is

    type Direction_Type is new Angles.Proper_Angle_Type;

    function North return Direction_Type renames Zero;

    function Northeast return Direction_Type;
    -- = 45.0*Degree = 0.5*Quadrant

    function East return Direction_Type renames Quadrant;
    -- = 90.0*Degree

    function Southeast return Direction_Type;
    -- = 135.0*Degree = 1.5*Quadrant

    function South return Direction_Type renames Hemicycle;
    -- = 180.0*Degree = 2.0*Quadrant

    ... -- etc.

  end Directions;


And then somewhere:

  Direction : Directions.Direction_Type;
  -- I don't care what the units are,
  -- the abstraction protects me from them


> Furthermore, one is more likely to make this mistake:
> 
>   THETA_IN_RADIANS : Angles.Angle_Type;
> 
> than to make this mistake:
> 
>   THETA_IN_RADIANS : Angles.Degrees;
> 

Or perhaps:

    Theta_Angle : Angles.Angle_Type;
    -- I don't care what the units are,
    -- the abstraction protects me from them

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