Classes and packages - recommended practice

[Maciej Sobczak <no.spam@no.spam.com>]

Hi,

Let's take the basic example with three types:

- Shape  (abstract)
- Triangle
- Rectangle

I have learnt three options to represent them as packages.
Let's choose the Objects/Object naming convention for the package and 
the actual type - this is the first convention presented in:

http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#Class_names


1. Make a separate package for each class.

This means that there are 6 files (3x ads + 3x adb). None of the 
packages is a child or nested withing another.

The client code may do the following to be able to use all names without 
qualification:

with Shapes;
use Shapes;
with Triangles;
use Triangles;
with Rectangles;
use Rectangles;

2. Make a root package Shapes and have the leaf classes in child packages.

This means that there are still 6 files.

The client code may do this:

with Shapes;
use Shapes;
with Shapes.Triangles;
use Shapes.Triangles;
with Shapes.Rectangles;
use Shapes.Rectangles;

3. Make a single package Shapes and have two *nested* packages for 
Triangles and Rectangles.

This means that there are only two files (shapes.ads and shapes.adb).

The client code may do this:

with Shapes;
use Shapes;
use Shapes.Triangles;
use Shapes.Rectangles;


My question is - when do you use which form?
The third options seems nice because it is compact. Not only there are 
just two files to mess with, but the "locality of reference" (in the 
sense of reading the source code) is higher when the whole hierarchy can 
be viewed in a single place. The problem is that this seems to be 
applicable only to closed hierarchies, when no new classes are likely to 
be added. Still, there are cases when that's exactly the case (for 
example, when the set of derived classes completely partition the 
superclass).
Second option (with child packages) seems interesting, because it is 
open for extension (no need to edit existing files when adding new 
sibling classes), and at the same time the relations between classes are 
expressed in package names (and file names) as well, which can ease 
navigation in the project.
First option is, well, ... so what would you say about the first option?

What do you recommend and when? Are the issues above the only ones that 
can be taken into account?

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/