Re: type names (was Re: Child package: private type and IO)

[blaak@infomatch.com (Ray Blaak)]

Whoops! I seem to have touched a nerve.

I know what a type is and agree with your (Matthew's) explanation. I know what
module is and approve of Ada's separation of namespaces from types.

As for finding the style of, for example, Lists.List irritating as compared to
List.Object, well, I am not *that* irritated. I am certainly not upset about
the names in the standard Ada packages.

mheaney@ni.net (Matthew Heaney) writes: 
> And by the way, while I'm on the subject, a "class" in other languages as
> C++, Eiffel, and Java maps to an Ada tagged type.  It does NOT map to an
> Ada package.

A class in these languages defines both a namespace and a type. To map it to
Ada one has to bring in both mechanisms. Either one in isolation will not be
sufficient.

> Of course, a type name should NOT be qualified by a package name.  A type
> name is a type name, and a package name is a package name.  A package name
> is NOT a type name, and in no way participates in naming a type.
>
> A package is a namespace, and serves only to prevent clashes among
> similarly named types in an otherwise global namespace.  A package
> disambiguates type names, but it is itself not a type name.

But it is a very common Ada style to qualified names throughout a
program. What is the "use clauses are evil" debate all about, after all? And
given a qualified naming style, having names read well considering the package
name is also important.

As for confusing the difference between a module and a type, I don't see the
problem. If one writes in a style that dedicates a package for each (main)
type, and uses a qualified naming style, then knowing the package *is*
important when dealing with a particular type and its operations.

I did not make up the P.Object style. I was introduced to it when working on a
large air traffic control project. It so happened that I got used to it and
now like it.

Consider a discussion about a particular object called L: "What kind of object
is it?" "It is a list object." "Oh! That means I can do this and that with
it." Having the declaration "L : List.Object" is not an unreasonable way to
convey this information.

> A bunch of guys from all over the planet with PhDs in computer science 
> designed the language, and somehow they didn't come up with your "better
> idea."  Telling, isn't it?  If you think it is an improvement, perhaps that
> is because there is knowledge that you don't have.

It is more likely that I have the knowledge but have a different opinion
anyway. Come on, people differ! These PhDs argued like crazy during the design
phase of Ada, and things will continue to evolve.

But so what? My real opinion about all this is not so much that a particular
style is objectively better than another, but that any project should use a
consistent style, whatever it is. Following the LRM is certainly a good idea
as any.

Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.