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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7eaf9f2597de2259 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-08 12:09:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: on package naming, should the word "_pkg" be part of it? Date: 08 Oct 2001 15:06:54 -0400 Organization: NASA Goddard Space Flight Center Message-ID: References: <9pif1o01btl@drn.newsguy.com> <3BBD12F1.9BED0B70@acm.org> <3BC0B1D4.21C79A8@acm.org> <3BC1DB22.E127B53D@boeing.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1002568120 26165 128.183.220.71 (8 Oct 2001 19:08:40 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 8 Oct 2001 19:08:40 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:13959 Date: 2001-10-08T19:08:40+00:00 List-Id: Jeffrey Carter writes: > Stephen Leake wrote: > > > > I use _Type. The reason is that types and objects share the same > > namespace, yet the most reasonable name for an object and a type is > > the same: > > > > type Car is record ... end record; > > > > Car : Car; > > > > This is natural, but illegal. The easiest (for _me_, not for > > everyone!) way to resolve it is to add some "noise" to either the > > object or the type. Since the object name will appear more often than > > the type, I add noise to the type: > > No, it's not natural. Well, it is for me, in the situations I have encounterd so far. Celebrate diversity :). > What might be natural is > > VIN_ABC1234567JKLK67 : Car; That's solving a different problem than I had in mind; you are assuming you need one named Ada object per physical car. My example is way too short for you to jump to this conclusion. See my other post for a better example (primitive operations of a type). > Car : Chevy_1957; Still another problem; each model of car should have a different type. > More realistically, > > Current_Vehicle : Car; Still another problem; iterating thru a collection. > Even this is incorrect. Current_Vehicle is not a car, it is a > collection of information about a car: > > Current_Vehicle : Car_Info; Actually, I would have assumed it was a collection of information about a vehicle, which might not be a 'car': Vehicle_Info : Vehicle_Info_Type; :). > The developer thinks, "This type is a collection of information > about cars, so its name should be > Collection_Of_Information_About_Cars, or Car_Info for short." Or > something like that. Car_Info : Car_Info_Type; > Further, there is generally no problem with object names, since > objects of the type are generally not declared in the same scope: > > Car : Car_Handler.Car; Well, sometimes this is true, but not _always_. In particular, primitive operations of tagged types _must_ be declared in the same scope as the type. And I don't want a separate convention for that! > It is parameter names defined in the same scope that are perceived > as a problem. In many cases, even parameter names are not a problem. > When inserting into a list, Into seems a better parameter name than > List; when iterating over a structure, Over seems better than List, > Queue, or Stack, and so on. Not to me. Sometimes you can make the function call read more "naturally" with parameter names like "Into". But the body reads very oddly, unless you use renames on the parameters, which is error-prone. > Maybe _Info is still noise, but it seems like more reasoned noise > than _Type. If the object is simply to put some noise on the end of > type names to distinguish them from parameter names, then _T seems > as good as any other noise. Yes, _T is a good choice. I'm not entirely sure why I originally chose _Type instead of _T. At this point, there are many in the Ada comunity that use _Type; I don't know of any that use _T. So _Type wins. > Another "solution" I have seen is > > > > Never a name problem! Unless you need tagged types and primitive operations. As I said in another post, you can come up with alternate solutions to any particular instance of _Type. But _Type is the simplest one that works _everywhere_. It's nice to have one naming convention, rather than several. Another strong argument here is that you can get used to any style, after a while. The exact details of the style matter far less than having a consistent style in the first place. For this particular style question, Ada imposes a constraint; objects and types share a namespace. Any solution to this constraint is acceptable. I like _Type because it is mindless (I have plenty of other things to think about), and works _everywhere_. But if I was on a project that had a different convention, I would adapt (although, sometimes resistance is _not_ useless :). -- -- Stephe