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

[mheaney@ni.net (Matthew Heaney)]

In article <6dcio1$fvo$1@berlin.infomatch.com>, 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.

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

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.
   
It is completely wrong to name a type "Object."  There are 2 reasons:

1) It confuses the difference between a memory cell (which merely stores a
value) and the value itself.  "Type" refers to a set of values, and to the
operations you can perform to manipulate those values.

"Type" does NOT refer to the memory cell containing a value.  The term we
use to refer to a memory cell containing a value is "Object."

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."

The name "T" is the name we've bound to the TYPE, not to the object.  So
"T" is the name by which we refer to a set of values and a set of
operations.  The name "O" is the name we bind to an OBJECT, not a type;
that is, "O" refers to a memory cell.

So when you name a type "Object," it's confusing because the term "Object"
refers to a memory cell.  But a type is NOT a memory call, it's a set of
values.

2) It confuses the difference between a module and a type.

In Ada, module and type are ORTHOGONAL language features.  This really
confuses a lot of people, and I have no idea why.

The Ada language construct for a module is a package.  A package is NOT a
type.  A package which exports a type declaration merely demarcates the
"primitive" operations of a type among all the operations that have the
type as a parameter or return value.  

The Ada language construct for a type comprises 2 parts:

a) a type declaration, which binds a name to the type, specifies its class,
and specifies the set of values as a range (or implied range).

b) subprogram declarations, which take parameters of the type, or return
values of the type.

Consider this example:

package P is

   type T is range 1 .. 4;

   procedure Op1 (O : T);

   function Op2 (F : Float) return T;

end P;

with P;
package Q is

   procedure Op3 (O : P.T);

end Q;

Let's analyze this piece by piece.

The declaration 

   type T is range 1 .. 4;

a) specifies the type class, here Integer

b) specifies the set of values (having the Integer class) for the type,
here 1, 2, 3, 4

c) binds a name to the type, here "T"

d) specifies primitive operations that are "predefined" for this class of
type, here

   +: T x T -> T
   +: T -> T
   -: T x T -> T
   -: T -> T
   =: T x T -> Boolean

etc

The operations Op1 and Op2 are also "primitive" operations of the type
whose name is T.  We say they are "user-defined," in contrast to the
"predefined" primitive operations as addition, subtraction, etc.

They are primitive because they take a parameter of the type (Op1) and
return a value of the type (Op2), and they are declared in the same package
(P) as the type declaration.

By contrast, the operation Op3 is NOT a "primitive" operation of the type
whose name is T.  Even though Op3 takes a parameter of type P.T, it is not
primitive because it is not declared in the same package as the type
declaration.

We make the distinction between primitive and non-primitive operations
because only the former are "inherited" during a derivation.  For example,

with P;
package R is

   type NT is new P.T;

  procedure Op4 (O : NT);

end R;

The primitive operations of type R.NT are "+", "-", "*", "/", etc, and Op1,
Op2, and Op4.  Op1 and Op2 (and addition, etc) are inherited from T, and a
new primitive operation, Op4, was added too.

Note the Op3 is NOT an operation of type NT, because Op3 is not a primitive
operation of type T.

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.  To convert the C++ declaration

class Stack ...;

to Ada, you have to do this:

package Stacks is

   type Stack is ...;  -- this is the "class Stack"


>>So when refer to an object's type as "Object," then how do you refer to the
>>object?
>
>Perhaps as An_Object, or The_List, or The_Set, or even Value. An even better
>approach is to use names from the domain, like maybe Employees, or
>Active_Flights, or Current_Account.

An an even better approach is

Account : Bank_Account;

File : Text_File;

Mode : File_Mode;


>>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.  

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.

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.

>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, as in


generic
...
package Stacks

   type Stack is ...;
...;
end Stacks;

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.

> 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.

>Note this does not imply that all types should be
>called "Object" either. With this example in particular, it is natural to work
>with objects and references to objects:
>
>  type Handle;
>  type Object is record
>    ...
>        Next : Handle;
>        Previous : Handle;
>  end record;
>  type Handle is access Object;


This is another horrible naming convention.  The term "handle" loosely
refers to a pointer-to-pointer.  Handles are used in memory allocation
schemes to allow you to relocate chunks of memory to reduce fragmentation
(Mac programmers will know what I'm talking about).

The Ada idiom for a name of an access type is T_Access, for example

type Stack is tagged private;

type Stack_Access is access all Stack;

type Stack_Class_Access is access all Stack'Class;

Do not name an access type Handle, because it is not a handle.

Do not name an access type Pointer, because access objects are not
pointers.  If they were, then Jean Ichbiah would have chosen the keyword
"pointer" instead of "access," right?

If you don't believe that this is the Ada idiom, then make note of the
names of the types

Ada.Text_IO.File_Access

Ada.Strings.Unbounded.String_Access

Ada.Streams.Stream_IO.Stream_Access


>then one can say things like:
>
>  Manager_Subset : Linked_List.Handle;
>
>which is really clear (to me, of course :-).
>
>If one uses use clauses a lot, then of course more descriptive type names are
>better:
>
>  data : Linked_List;

Ahh, that's more like it.

Here's an example from a library I'm writing:

package ACL.Lists is ...;


package ACL.Lists.Single is

   type Single_List is private;
...;
end ACL.Lists.Single;


package ACL.Lists.Double is

   type Double_List is private;
...
end ACL.Lists.Double;


Here's another example you often find in tutorials:

package Bank_Accounts is

   type Bank_Account is abstract tagged limited private;
...;
end Bank_Accounts;


package Bank_Accounts.Checking is

   type Checking_Account is new Bank_Account with private;
...;
end Bank_Accounts.Checking;


package Bank_Accounts.Savings is

   type Savings_Account is new Bank_Account with private;
...
end Bank_Accounts.Savings;


>>A good guideline is, Be consistant with the style in the reference manual. 
>>There are NO types in the RM named "Object," so there should be none in
>>your code either.
>
>One shouldn't be so afraid to do something different, if one thinks it is an
>improvement. How else can standards get better?

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.