Re: Visibility problems with package instantiations.....

[Stephen Leake <Stephe.Leake@nasa.gov>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
> >> Fryklund) wrote:
> >
> >> >Our CM policy
> >> >also dictates a directory structure with every unit in it's own branch
> >> >leading to a large tree.
> >> 
> >> It is a reasonable policy.
> >
> >Maybe for Java, which requires that directory structure anyway.
> >
> >But for Ada, which has a good way to name files that indicates the
> >package heirarchy, directories should be used for even higher level
> >organization, like projects.
> 
> For a small or medium sized project one can indeed pack everything in
> one directory. With hundreds of files it becomes rather difficult. 

Why? I don't have a problem with 280 files on Windows 2000. What sorts
of problems do you run into?

> So if there is no good code management system or IDE, it becomes
> reasonable to have separate directories for project branches [mapped
> to packages].

You are using the term "branches" in a way that is different than I'm
used to; I use it in the context of configuration management, to mean
a different development path of the same set of code; for a release,
or for an experimental new feature.

> BTW, maybe a stupid idea, but what if we change file naming policy
> allowing:
> 
>    package A.B is ...
> 
> to be named "b.ads" IFF that is placed in a subdirectory named "a" of
> the directory containing "a.ads"?

You can try that, but you have to get the compiler to support it.
That's unlikely; most require a unique file name, _independent_ of the
directory. 

-- 
-- Stephe