Re: Naming convention for classes?

[Jeffrey Carter <spam@spam.com>]

Peter C. Chapin wrote:

> package Date is
>   type Object is private;
> 
>   procedure Advance(Item : in out Object; Step : in Integer);
>   ...
> end Date;
> 
> The I can create Date objects by first withing Date and then doing
> 
>   Today : Date.Object;
>   ...
>   Date.Advance(Today, 100);
> 
> package My_Library is
>   type Date is private;
> 
>   procedure Advance(Item : in out Date; Step : in Integer);
>   ...
> end My_Library;
> 
> Then I might with My_Library and use My_Library and do
> 
>   Today : Date;
>   ...
>   Advance(Today, 100);

Is this a troll? You'll find ample discussion of this (naming types and 
packages) if you search c.l.a at groups.google.com. Some people are very 
attached to one approach or the other.

The 2 approaches you mention are called "use unfriendly" and "use 
friendly", respectively. There are arguments for and against both 
approaches. Ada's standard packages are use friendly. For example, 
package Ada.Strings.Unbounded declares type Unbounded_String.

If you create use friendly packages, you should not consider the package 
name to be noise. "Ada.Strings.Unbounded" is not just noise.

One approach is to use appropriate suffixes to create useful names:

package Date_Handling is
    type Date_Info is private;

    procedure Advance (Date : in out Date_Info; Num_Days : in Positive);

Note that with this approach the reader can tell that you're advancing a 
date by a number of days without any comments. Note also that negative 
numbers of days are not allowed, as that would not be considered 
advancing a date.

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06