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

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

Sorry I got abrasive before, I don't really mean to start a flame war
either.  But to address your points:

W. Wesley Groleau (Wes) wrote:
> 
> So you are suggesting I have independent objects all named "Angle"
> all over the place?

Sure. Why not?

  package Angles is

    type Angle_Type is digits ...;  -- in degrees

    subtype Proper_Angle_Type is
      Angle_Type range 0.0 .. Angle_Type'Pred(360.0);

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

    -- Angle_Type primitives (inheritable on derivation):

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

    function Get_Supplement     -- = 180 - 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;

    ...
  end Angles;

Here are at least 4 functions that contribute to an abstraction for
Angles, there may be many more.  Each of these functions takes an Angle
and transforms it in some way.  What shall we name the parameter in
each? With "Angle_Type" as the name of the type, the simple name "Angle"
is available.  But if the type were already named "Angle", we'd have to
find something else for the parameters.  Should it be "The_Angle", as
Booch would suggest?  Do we have to resort to barbarous abbreviations
such as "Ang" or "A"?  Do we need to spend (i.e., waste) time hunting
around for synonym for "Angle"? 

> You apparently
> need to clarify, "presumably an object and  its type _both_ represent
> the _same_ concept"

Maybe taking an example will help: What we have here is the concept of
an "Angle" -- what one is, and what we can do with one. We have a
package that encapsulates this concept, a type that implements a data
abstraction for this concept, and formal parameters standing for
instances of this concept being acted upon by primitive subprograms. 
One concept, versus multiple program entities all needing names that
don't clash.

Semantic economy means that I should only need to decide on the word
that stands for the concept ("Angle"). At that point, the creative work
of naming should be done, end of story.  The names for the program
entities should fall out automatically, without mental work:

  concept: "Angle"  -->  instance:  "Angle"
                    -->  type:      "Angle_Type"
                    -->  package:   "Angles"


> > 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;
>  [snip]
> > My scheme has the advantage that a "specific" identifier such as
> > "Start_Angle" is clearly the name of an object, ....
> 
> ...(and "specific" is the way AQS recommends making the distinction)...
> 
> > ... and can never be confused as the name of a "specific" derived-
> > or sub-type of  Angle_Type.
> 
> in a group of statements, it's rather hard to confuse _any_ identifier
> as the name of any (sub)type.  It's also difficult to misinterpret
> whether a colon is to the left or right of the identifier.

Once correctly written and successfully compiled, that may be true.  But
when an author is actually in the process of writing the abstraction (or
even some client code that uses the abstraction) keeping track of which
identifiers stand for the types, vs the packages, vs the
objects/parameters, vs the primitive subprograms, is easier to do if the
distinctions between the identifiers follow simple systematic rules.

> Where besides in a few pragmas) is such confusion possible?

Booch-like style:

  package Angle_Set is new Set
    (Item  => Angle,
     Count => Angle_Count); -- is this a type or a constant?

Cohen-like style:

  package Angle_Sets is new Sets
    (Item_Type  => Angle_Type,
     Count_Type => Angle_Count_Type);

But, more important than any confusion on the page, there's the
confusion in the mind, when the software is thought about or discussed.
Although Robert Dewar has made the point that source code
editors/browsers with cross-reference capabilities now make it easier to
trace back to the original definition of an identifier, IMHO if the only
reason you're bouncing back to the definition is just to recall what
various things were named, then it's a waste, no matter how facilitated
the bouncing.  Better if you didn't have to bounce at all, but instead
could just rely on a naming system that only requires you to remember
what _concepts_ (object classes) you have in your application.

(Clarification: I do think that this kind of cross reference browsing
feature is useful, when it's applied to helping the reader understand
the _semantics_ of the program, rather than just surface aspects like
naming. For example, bouncing back to a type declaration to see what
record components it contains, or bouncing to the body of a procedure to
see exactly what algorithm is implemented there.)
 
> In other words, you object to a recommendation that we _avoid_
> "information hiding"  :-) 

Quite.

> I object to that even more than I object to a blanket "_Type" suffix.

Good.

> I use "_Type" myself once in a while (on this
> project, alwaysm its the law :-) ) but I still hold to my opinions that
> it
> is usually just five characters of "noise". 

Seems like quantum mechanics must apply to software, because this noise
appears to be irreducible given the structure of the language.  (To me,
abbreviations are noise. :-) ) We're forced to distinguish identifiers
somehow, but any distinction means adding some amount of noise. I just
think distinctions that are self-evident in the surface form (syntax) of
the identifiers is less mental work distinctions buried in the meanings
(i.e. semantics) of the identifiers (e.g., "specific" vs. "general").

My question to you is this: is the "The_" in "The_Angle" noise?  

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