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

[blaak@infomatch.com (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.