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

[fjh@cs.mu.OZ.AU (Fergus Henderson)]

mheaney@ni.net (Matthew Heaney) writes:

 >blaak@infomatch.com (Ray Blaak) wrote:
 >
 >>>Objects are the memory locations that store a value of a type.
 >>
 >>But you are using the word here as a type! (i.e. the set of things that are
 >>memory locations that store values).
 >
 >No.  You are confused about what a type is.

No, Ray Blaak is correct here.

 >Let's begin by defining what we mean by a type.  A type is defined as "A
 >set of values, and a set of operations on those values."  For example,  I
 >can define a type
 >
 >with the name "Integer"
 >
 >and the set of values
 >
 >   ..., -3, -2, -1, 0, 1, 2, 3, ...
 >
 >and the set of operations
 >
 >   +: Integer x Integer -> Integer
 >   -: Integer x Integer -> Integer
 >   *: Integer x Integer -> Integer
 >   /: Integer x Integer -> Integer
 >   =: Integer x Integer -> Boolean
 >
 >etc

Agreed.

Above, you used the word "Object" to refer to a type with the name "Object",
with the set of values being the different possible memory locations,
and with the set of operations being fetch, store, etc.

Below, you assume that "Object" and "Type" are mutually exclusive;
this is true in Ada, but there are other languages for which it is not true.

 >A type refers to the set of values, NOT the objects.  An object is a memory
 >location inside a computer, that stores a value, a value we interpret as
 >having a certain type.  So when we declare an object,
 >
 >O : T;
 >
 >we're allocating a memory cell, and we're interpreting the value of the
 >data in that cell as being of type T.  The means the memory cell designated
 >by object O will only contain certain values, and that only certain
 >operations may be applied to the value in that cell.
 >
 >The memory cell designated by object O isn't really interesting.  It's the
 >data in that cell that's interesting.  And it's the data in the cell that
 >"is of type T," not the object itself.

No, the object itself "is [an lvalue] of type T".

To say otherwise would imply that objects are untyped, that
only values are typed, and that it is therefore possible to
store a value of any type in a given object.  This is true
for some untyped languages, but it is not true in Ada.

 >It is completely wrong to name a type "Object."

Well, I don't particularly like this convention much myself;
but I think "completely wrong" is overstating the case.

 >Yes, it's true we often say "Object O has type T," but we really mean "O is
 >the name of a memory cell containing a value of type T."

No.  What we really mean is "O has type n<T>",
where "n<T>" is a (parametric) type whose operations
include "fetch" (syntactically implicit in Ada) and "store" (`:=').

"n<T>" might be better named "name<T>", "lvalue<T>", or even "object<T>".

 >>>A type should be named using a noun phrase, such as
 >>>type Singly_Linked_List is ...;
 >>
 >>I think that style of type names used really depends on if type names are
 >>qualified with package names or not.
 >
 >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.  

No, a package name surely does participate in naming a type,
for the type's fully-qualified name includes the name of the
package in which it is contained.

 >A package is a namespace, and serves only to prevent clashes among
 >similarly named types in an otherwise global namespace.

No, packages also provide encapsulation, not just namespace control.

 >A package disambiguates type names, but it is itself not a type name.

Agreed.

 >To use a package as part of the type, as in 
 >
 >package P is 
 >
 >   type Object is ...;
 >...
 >end P;
 >
 >The_Object : P.Object;
 >
 >so that the "real" type name is "P.Object" only confuses the difference
 >between a module and a type.

Nonsense!

The package name is P; the type name is P.Object
(though it can be abbreviated as Object, in certain contexts).
What's there to be confused about?

 >>Having:
 >>
 >>  package Linked_List is
 >>    type Linked_List is ...
 >>  end Linked_List;
 >>
 >>results in usage like:
 >>
 >>  Employees : Linked_List.Linked_List;
 >>
 >>which I personally find irritating.
 >
 >The package is misnamed.  A common idiom, and a very OLD idiom in the Ada
 >community, is to use the plural of the type name as the package name,

Well, that doesn't help much -- now the usage is

    Employees : Linked_Lists.Linked_List;

which is still just as ugly.

 >I'm sorry you find this convention irritating.  If so, then you can tell
 >the language designers that they named the packages
 >
 >Ada.Characters
 >Ada.Interrupts
 >Ada.Interrupts.Names
 >Ada.Exceptions
 >Ada.Numerics
 >Ada.Streams
 >Ada.Strings
 >Interfaces
 >Interfaces.C.Pointers
 >Interfaces.C.Strings
 >System.Address_To_Access_Conversions
 >System.Storage_Elements
 >System.Storage_Pools
 >
 >incorrectly, and that the names they chose irritate you.

It's not a question of "correct" or "incorrect", it's a question
of style.  The style chosen for the standard library strongly
encourages the use of `use', to avoid unnecessary redundancy in
names like `Ada.Strings.Unbounded.Unbounded_String'.
This is probably not such a bad thing
for the standard library, since experienced Ada programmers 
will know the standard library well; but for more general settings,
encouraging the use of `use' may not be such a good idea.

Personally, I quite like the style of naming types `T',
e.g. `Ada.Strings.Unbounded.T'.

 >> However a package like:
 >>
 >>  package Linked_List is
 >>    type Object is ...
 >>  end Linked_List;
 >>
 >>results in usage like:
 >>
 >>  Employees : Linked_List.Object;
 >>
 >>which reads better to me.
 >
 >It reads better to you because you are confused.  You don't understand the
 >difference between a module and a type.

Well, it reads better to me too, and I definitely do
understand the difference between a module and a type
(and I think Ray Blaak probably does too).

 >If you don't believe that this is the Ada idiom, [...]

I think Ada is big enough for more than one idiom!

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F