Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney <matthew_heaney@acm.org>]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> >And whatever you do, please do NOT name a type "Object" or "Instance".
> >This is a sure sign of confusion about the difference between a module
> >and a type, which are orthogonal language features in Ada.
> >
> Well, since I was the first one to publish that notation (I do not claim to
> be the first one who thought of it), let me follow up.

Jean-Pierre: I loved your other article in ACM, "What Orientation Should
Ada Objects Take," but "didn't care for" the one you mention above, in
Ada Letters.
 
> We are talking about classes here, and a class is an encapsulation of a data
> type together with operations. In that sense, a type is certainly not a
> class, since it addresses only the data-type part of a class.

This is wrong.  The defination of a type has _always_ been "data +
operations."  The term "class" to designate a type is an unfortunate
mistake make by the designers of Simula.
 
> Rather, a class is a certain way of using a package, to declare a type and
> associated operations (methods), and nothing else. 

I prefer to refer to such a package as "a package that exports an
abstract data type" or just "an ADT package."  To refer to such a
package as a "class" is incorrect, because a package is a module, not a
type.

The use of the convention "P.Instance" to refer to the "real" type name
is very misguided, because it's as if you're trying to make a package
into a type, which it is not.

If the language designers had wanted module and type to be the same,
then they would have designed the language that way, and you wouldn't
need to say "type Instance is ..." at all.  

You might not like it, especially since this is probably perceived as
idiosyncratic by programmers who have used other object-oriented
languages (in which module and type are the same), but that's just the
way it is.  No coding convention is going to change this.

> However, if you agree that such a package corresponds to what is called a
> class in OO languages, then it makes sense to name the package, not the
> type, after the entity you want to represent. 

No, I do most certainly do NOT agree that a package is equivalent to a
class in other languages.  A class is a type, and we already have types
in Ada.  All a package does in Ada is to demarcate which operations of
the type are primitive.

The "real" name of the type is the identifier used in the type
declaration, never the name of the enclosing package.

> Now the package may declare
> some utility types in addition to the "main" type; it makes sense to have
> some notation to distinguish this main type. "Instance" or "Object" look
> nice in a declaration like:
>     My_Account: Bank_Account.Instance;

You may think it looks nice, but I read this and think "Je crois qu'elle
est laide."  Why not just
   My_Account: Bank_Account;

You know, the way the language designers intended?
 
> but this is not the main point. The really important point is to use the
> same name for the main type of every  "class package", because it allows you
> to have a uniform convention

I don't understand what you mean.  We've been calling files File_Type
for almost 20 years, and so far no one has complained.

> A full discussion of these issues can be found in the paper "a naming
> convention for classes in Ada 9X" which appeared in Ada Letters by the end
> of 94 (sorry, I don't have the exact reference at hand).

We obviously have philosophical differences about the nature of a type.
Oh, well.  I'll be in Paris in September: perhaps we can meet at a cafe
to discuss it more over "une pression"!