Child package: private type and IO

Child package: private type and IO

[johnjohn]

I'm trying to write two separate packages, one for a private
type and constructor, and the other an IO package.  House
rules. :(

The need, obviously, is for the IO package to be able to
access the private type internals, a feature which seems
to be supported via the child package system.  It's unclear
to me, however, exactly how a package is declared to be
a child of the original.

Picking up Skansholm's Ada From the Beginning, usually a pretty
good resource, is particularly emptly on package externals (file
extensions, for example).

Actually, now that I say that, Skansholm does have a reference
to naming a child package "PARENT_PKG.CHILD_NAME".

However, using this convention gets me the following compilation
error on the "with" declaration:  
file "parent_pkg-child_name.ads" not found

Any tips?  Any pointers to a better handling of child packages?

Thanks.

John

Re: Child package: private type and IO

[Tom Moran]

>to naming a child package "PARENT_PKG.CHILD_NAME".
But a child needn't 'with' its parent - that, and 'use', are
automatic.

Re: Child package: private type and IO

[sparre]

John <johnjohn@triceratops.com> wrote:

> I'm trying to write two separate packages, one for a private
> type and constructor, and the other an IO package.  House
> rules. :(

Good rules!

I would have been nice if you posted more code (and told us that you are using
GNAT :-).

GNAT has some rather strict rules for the names of source files. If you are in
doubt about them, run "gnatchop" on your individual source files, and see how
it splits the source up and names the files.

A parent-client package example:

   --  file: parent.ads

   package Parent is

      type Object is ...;

      function Initialise return Object;

   end Parent;

   --  file: parent-child.ads

   with Ada.Text_IO;

   package Parent.Child is

      procedure Put (File : in     Ada.Text_IO.File_Type;
                     Item : in     Object);

      procedure Get (File : in     Ada.Text_IO.File_Type;
                     Item :    out Object);

   end Parent.Child;

You will of cause also need implementations (package bodies) for these
specifications.

Jacob Sparre Andersen

-- Have you played with your LEGO today?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Child package: private type and IO

[Matthew Heaney]

In article <6cbuat$cg3$1@nnrp1.dejanews.com>, sparre@cats.nbi.dk wrote:


>A parent-client package example:
>
>   --  file: parent.ads
>
>   package Parent is
>
>      type Object is ...;
>
>      function Initialise return Object;
>
>   end Parent;

Note that this is NOT the way to organize this package if type Object is
tagged.  For a tagged type, constructors - defined as functions returning a
value of the type - should return the class-wide type, or should be
declared in a nested package, ie

package P is

   type T is tagged ...;

   package Constructors is

      function New_T return T;

   end;
...
end P;

-or-

package P is

   type T is tagged ...;

   function New_T return T'Class;
...
end P;


The problem is that very often you use the "transitivity of visibility"
technique to get direct visitibility to the type and its operations, with a
null extension, ie

   type NT is new P.T with null record;

but if T has primitive operations that are functions returning type T, then
type NT "goes abstract," and the poor client has to override them.  This is
NOT what you want to have happen.

By declaring the constructor in a nested package, then the function isn't
primitive anymore, and so it is not inherited.  Therefore, any derivation
doesn't go abstract, because there are not inheritable functions that
return the specific type.

The same effect may be achieved by making the return type class-wide.  Then
the function is no longer primitive, and so is not inherited during a
derivation.  Therefore, the derived type does not go abstract, which is the
behavior we want.

I'll also make an Ada style point.  Please do not name a type "type Object
is..."  This is VERY confusing, because an object is an object, not a type. 
Objects are the memory locations that store a value of a type.  So when
refer to an object's type as "Object," then how do you refer to the object?

A type should be named using a noun phrase, such as

type Text_File is  ...;

type Singly_Linked_List is ...;

type Storage_Element_Array is array ...;

type Ownship_Heading is ...;

type Integer is ...;

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.

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

[Ray Blaak]

mheaney@ni.net (Matthew Heaney) writes:
>I'll also make an Ada style point.  Please do not name a type "type Object
>is..."  This is VERY confusing, because an object is an object, not a type. 

I am sure this is a periodic topic that has been rehashed to death, but I
can't resist...

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

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

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

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;

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

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.

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

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

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

[Brian Rogoff]

On Sun, 1 Mar 1998, Matthew Heaney wrote:
> 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.
> 
> ... stuff I mostly agree with deleted ...
>
> In Ada, module and type are ORTHOGONAL language features.  This really
> confuses a lot of people, and I have no idea why.

Many programmers began their OO programming with (early) C++, or
Smalltalk, or may have read "Object Oriented Software Construction", and 
consider the conflation of module and type into class to be fundamental.
Perhaps Java programmers and "new C++" programmers will have an easier 
time of it, but I doubt it. 

OTOH, in some ways modules can be said to have a "type"; the ML family of 
languages (of which SML and Objective CAML are instances) have module 
systems in which modules ("structures" in ML) have "signatures" which are 
loosely like types, and "functors" which map structures to other
structures. Ada now provides some of this via generic formal package
parameters and null-bodied generic packages. 

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

Funny, one of the first papers on Ada 9X that I read used "_Ptr" to name 
access types. I guess you should tell the author that he is confused, even 
though he was technical director of the design team ;-).

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

A bunch of guys with PhDs from all over the planet think Ada sucks, some 
of them are very well respected too. Which PhDs are right? 

Argument from authority is unhelpful; while I agree (mostly) with every 
guideline you set forth, and found Ray's naming schemes awful, Ray Blaak
is right with his final lines. Try things out if you think you have a 
better way. 

-- Brian

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

[Matthew Heaney]

In article <Pine.BSF.3.96.980301192928.4408A-100000@shell5.ba.best.com>,
Brian Rogoff <bpr@shell5.ba.best.com> wrote:


>> 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.
>
>A bunch of guys with PhDs from all over the planet think Ada sucks, some 
>of them are very well respected too. Which PhDs are right? 

The PhDs that like Ada, of course. :-)

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

[Brian Rogoff]

Amazing how much this naming style issue comes up here :-).

On 4 Mar 1998, Fergus Henderson wrote:
>  >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.

FWIW, using the plural package name style I would probably chose either 

	Employees : Linked_Lists.List_Type;

or 

	Employees : Linked_Lists.List_T;

which may still be just as ugly (at least to Matthew) but makes clear 
which part of the name is the type name, even in the presence of a 
use clause. I've yet to determine whether I feel an _Class suffix is 
also appropriate for access to classwide type; I know I don't like the 
"_Access" for Stream_Access.

> It's not a question of "correct" or "incorrect", it's a question
> of style.

I couldn't agree more.

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

Why not? ;-)

OK, I shouldn't be provoking the anti-use faction here, but since you 
can use use in a restricted scope, I don't see why draconian policies on 
its use are acceptable (SPARK and similar technologies excepted). 

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

What about when there is more than one type per package? I suppose in 
many cases (by analogy with inheritance hierarchies) there is really a
main type, so you might have

	Collections.Lists.T;
	Collections.Lists.T_Iter;
	...

but I'm interested in reading about other styles that people have found 
pleasant, so please elaborate.

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

Indeed. 

-- Brian

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

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

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

[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

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

[John G. Volan]

Brian Rogoff wrote:
> 
> Amazing how much this naming style issue comes up here :-).

Indeed. :-) 

> FWIW, using the plural package name style I would probably chose either
> 
>         Employees : Linked_Lists.List_Type;
> 
> or
> 
>         Employees : Linked_Lists.List_T;
> 
> which may still be just as ugly (at least to Matthew) but makes clear
> which part of the name is the type name, even in the presence of a
> use clause. 

This scheme still doesn't give Ada programmers enough to go on to deal
with most real-world programming situations.  For instance, it seems to
me that there might be other sorts of lists in this program other than
just lists of employees (for instance, lists of companies), so it would
be unwise to use "List_Type" and "Linked_Lists" for a type and package
that only support lists of employees. And the same program might very
well make use of other kinds of employee collections than just employee
lists (for instance, employee sets or employee queues), so to name a
given variable simply "Employees", without conveying whether it is a
list or set or queue of employees, is also unwise. Besides, "Employees"
might already be the name of a package containing a type called
"Employee_Type".

I would favor the following convention:

    Employee_List  : Employee_Lists.Employee_List_Type; --*see footnote
    Employee_Set   : Employee_Sets.Employee_Set_Type;
    Employee_Queue : Employee_Queues.Employee_Queue_Type;
    Company_List   : Company_Lists.Company_List_Type;
    Company_Set    : Company_Sets.Company_Set_Type;

If you choose to use "use" (I'm not necessarily endorsing that), then
this becomes:

    Employee_List  : Employee_List_Type;
    Employee_Set   : Employee_Set_Type;
    Employee_Queue : Employee_Queue_Type;
    Company_List   : Company_List_Type;
    Company_Set    : Company_Set_Type;

In other words, be "semantically economical" when it comes to naming
things: An Ada type, its enclosing package, and all its instance
objects, can all be seen as just different manifestations of a single
abstract concept. So if you already have a pithy phrase that neatly
describes that abstraction (e.g., "employee list") then you shouldn't
waste time hunting for synonymous (and possibly less apt) phrases, just
for the sake of differentiating these various constructs. Instead, just
embed the same pithy phrase in the names of each of these constructs,
but find some systematic scheme for "marking" these names to
differentiate them. The more mechanical that sceme is, the better,
because it means less mental work for the programmer (and for the
readers!)  For instance (as demonstrated above):

(1) Mark the package name by using the plural: e.g. "Employee_Lists".

(2) Mark the type name by appending the suffix "_Type": e.g.
"Employee_List_Type".  (Or you could use "_T" if you must; the important
thing is to use your chosen marker consistently.)

(3) Reserve the unmarked form for an object name: e.g. "Employee_List". 
Use this whenever you're in a context where there's no compelling need
to distinguish that particular object from any other instance of that
type. Usually this means the object is the only instance of that type in
that context; often, this is a parameter to a subprogram.

(4) When there is a compelling reason to distinguish particular objects
(e.g., when you're dealing with more than one instance of the same type
in the same context), mark the object names by attaching adjectives that
are appropriate to the particular situation: e.g.,
"Active_Employee_List" versus "Terminated_Employee_List".

Note that most object-oriented languages make it somewhat easier than
Ada to establish a systematic, semantically-economical naming scheme,
for two reasons: (1) The "class" construct merges the roles of both a
package and a type, so there are fewer things to name.  (2) Other
languages tend to be case-sensitive, so capitalization is available as a
mechanism for "marking". For instance, instead of having to say:

    Employee_List : Employee_Lists.Employee_List_Type;

in Eiffel you could simply say:

    employeeList : EmployeeList;

and in Java or C++ this would be:

    EmployeeList employeeList;

where "EmployeeList" is the name of a class (=package+type) and
"employeeList" is the name of an object. The convention of marking class
names with initial uppercase and object names with initial lowercase
(and separating words by capitalization rather than underscores) is
well-accepted among folks using Smalltalk, C++, Java and Eiffel, so it's
become something of an industry standard.  

(Personally, after working in Java for several months, I've gotten to
like this convention. Now I find myself wishing Ada95 had gone the
case-sensitive route too... Oops! I can see another religious can of
worms opening up again... :-)

*Footnote:

The above scheme didn't consider the effect of using generics. For
example, suppose you have a generic package for linked lists:

    generic
      type Item_Type is private;
    package Lists is
      type List_Type is ...
      ...
    end Lists;

And suppose you instantiate this for different item types:

    package Employee_Lists is 
      new Lists (Item_Type => Employees.Employee_Type);
    package Company_Lists is
      new Lists (Item_Type => Companies.Company_Type);

Then what you'd have to say is:

    Employee_List : Employee_Lists.List_Type;
    Company_List  : Company_Lists.List_Type;

And you'd be forced to qualify the type names here, even if you used
"use".  

Unfortunately, when you instantiate a generic in Ada, you only get a new
package name; you don't get a new *type* name as well.  On the other
hand, in class-based OO languages that support generic templates, this
issue doesn't come up, because class=package+type. For instance, in C++,
you could have:

    typedef List<Employee> EmployeeList;
    typedef List<Company>  CompanyList;
    ...
    EmployeeList employeeList;
    CompanyList  companyList;

(When they get around to putting generic templates into Java, I
anticipate the situation will be similar.)

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*resumeBlip:*/ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );

Case sensitivity [was Re: type names (was Re: Child package: private type and IO)]

[Anonymous]

<6c2r0l$iic$1@madmax.keyway.net> <6cbuat$cg3$1@nnrp1.dejanews.com>
<mheaney-ya023680002702982024210001@news.ni.net>
<6dcio1$fvo$1@berlin.infomatch.com>
<mheaney-ya023680000103981905280001@news.ni.net>
<6dhghp$suv$1@mulga.cs.mu.OZ.AU>
<Pine.BSF.3.96.980303102557.142A-100000@shell5.ba.best.com>

On Wed, 04 Mar 1998 18:19:20 -0800, "John G. Volan"
<johnv@ac3i.dseg.ti.com> wrote:

> ...
> package and a type, so there are fewer things to name.  (2) Other
> languages tend to be case-sensitive, so capitalization is available as a
> mechanism for "marking". For instance, instead of having to say:
> ...

Let's see, I've used

FORTRAN
COBOL
APL
Pascal
BASIC
Databus
MOBOL-2
Several assemblers
C
LISP
SNOBOL
Ada

How many of these are case sensitive? One. So my experience is that
"other languages" (than Ada) tend not to be case sensitive.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"You brightly-colored, mealy-templed, cranberry-smelling, electric
donkey-bottom biters."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Case sensitivity [was Re: type names (was Re: Child package: private type and IO)]

[John G. Volan]

> On Wed, 04 Mar 1998 18:19:20 -0800, "John G. Volan"
> <johnv@ac3i.dseg.ti.com> wrote:
> 
> > ...
> > package and a type, so there are fewer things to name.  (2) Other
> > languages tend to be case-sensitive, so capitalization is available as a
> > mechanism for "marking". For instance, instead of having to say:
> > ...

Note that in the context of this paragraph it was pretty clear that I
was talking about other *object-oriented* languages.  Perhaps I should
have fully-qualified this sentence as: "The most popular modern
class-based object-oriented languages tend to be ..." :-)

Jeff Carter responded:
>
> Let's see, I've used
> 
> FORTRAN
> COBOL
> APL
> Pascal
> BASIC
> Databus
> MOBOL-2
> Several assemblers
> C
> LISP
> SNOBOL
> Ada
> 
> How many of these are case sensitive? One. So my experience is that
> "other languages" (than Ada) tend not to be case sensitive.

That's true, but out of the above set (to my knowledge) only Ada(95) is
a fully object-oriented language, per se. Okay, I'll give you Pascal if
you mean Object Pascal, and Lisp too if you mean CLOS, and COBOL as well
if you mean the recent object-oriented incarnation. (Not sure about
BASIC -- does e.g. Visual Basic do objects and classes?  Never heard of
MOBOL-2, what is that?)

So, of the major object-oriented contenders out there we have:

Case-Sensitive           Case-Insensitive
--------------           ----------------
Smalltalk                Ada
Eiffel                   Common Lisp Object System
C++                      Object Cobol (is that the name?)
Objective C              Object Pascal
Java
Modula-2/3

A 60%-40% split in favor of case-sensitivity. Hmm, not a landslide
victory ... but how useful and/or scientific is it to just list names of
languages? All that speaks to is the level of popularity of
case-sensitivity among the *designers* of object-oriented programming
languages. I'd wager if you did a scientific survey of object-oriented
*programmers* and weighted the scores by volume of actual *usage* of
these languages, the case :-) for case-sensitivity's popularity would be
pretty strong.

At any rate, my main point is not whether case-sensitivity is more
popular among object-oriented programmers than case-insensitivity (even
although I believe that to be true). And I'm not trying to make any
particular religious judgment about whether case-sensitivity is "better"
based solely on its popularity.

My point is simply that when case-sensitivity *is* available in an
object-oriented language, it somewhat reduces the mental workload for
the authors and readers of code: They don't need to resort to elaborate
schemes of agglutinating special suffixes or prefixes just to
distinguish object names from class/type names. Capitalization standards
alone can provide an adequate marking mechanism (at least to cover the
object-vs-class distinction).

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );