Re: on package naming, should the word "_pkg" be part of it?

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Jeffrey Carter <jeffrey.carter@boeing.com> 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
> 
> <snip non-tagged example>
> 
> 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