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

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On 02 Dec 2003 11:20:08 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

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

To find a file in that huge directory. Note also that a nested package
of level 5 could have name like:

   fuzzy.graph.handle.learning.implementation.ads

It becomes a pain to navigate across this directory. It is difficult
for human eye to recognize a postfix of a long name. So one have to
separate files in some way. One possible way is to mimic the package
tree. It is a reasonable way, but not the only one.

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

The difference is not that great. For example, in one of my projects,
there were many different layers of interfaces. Private, half-public,
public + their implementations in different environments. It was
reasonable to put the corresponding packages into different
directories. Then not surprisingly, the resulting directory tree
closely resembled one of the packages.

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

Surely

>That's unlikely; most require a unique file name, _independent_ of the
>directory. 

--
Regards,
Dmitry Kazakov
http://www.dmitry-kazakov.de