From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/12 Message-ID: <33779E0D.61F8@sprintmail.com>#1/1 X-Deja-AN: 241159992 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kn8ko$jcc@top.mitre.org> <1997May7.201035.2439@nosc.mil> <33727EEA.2092@sprintmail.com> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> <3373EAB5.73A0@sprintmail.com> <33776FA6.3F78@this.message> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-12T00:00:00+00:00 List-Id: 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? :-) "); ------------------------------------------------------------------------