Re: organizing deep source trees with child packages

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

On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Long file names, which are difficult to read.
> 
> I guess we'll just have to disagree about that.
> 
> Are long package names easier to read?

They are not long, fully qualified names are long.
 
>>> When do file names and package names _need_ to be different?
>>
>> Always. 
> 
> Why? Simple assertions don't get us anywhere.

"c:\mess\foo.adb" /= "Foo"
 
>> Especially when you have hundreds of generic package instances popping
>> everywhere. 
> 
> Why are generics a special case? 

Because they add a multiplication factor in the number of packages for each
varying generic formal parameter. Generics also adds a layer of indirection
instance <-> generic-body. It is just impossible to remember which is an
instance of what and where are instances with particular parameters.

> It can be difficult to come up with good names for generic packages and
> their instances. I solve that with a naming convention; the package name
> of a generic package must start with "Gen_".

Right, but that does not help much. You can have instances within generic
bodies and other bodies. With generic children you also have cascaded
instantiations along the packages tree path. It seems that we are talking
about different dimensions. My current project has 700+ units.

>> Pushing files into different directories makes things only worse. 
> 
> How, exactly?

You must also remember the directories. If you need to find a unit you
first have to go to its directory and then start searching.

>> The point is, when browsing a project you are not interested in files,
> 
> Depends on exactly why I'm "browsing".

While programming/reviewing/testing/debugging an Ada program.

>> you are looking for Ada units, 
> 
> Ok, I'll suppose I'm "browsing for Ada units". I'm still not clear what that
> means in detail. 
> 
> If I'm _searching_ for an Ada unit that deals with lists, I
> either:
> 
> 1) remember the full name exactly, and navigate there by file name
> (which matches the package name)
> 
> 2) open a directory that contains the library that probably contains the
> lists packages, and search for the string "list" in the file names.
> 
> If the IDE provides some other way to search for "list" in package
> names, that would be equally useful. (Does GPS let you search for
> strings in its file or package browser?)

It does, but it is far slower than browsing, because it involves typing,
browsing the results of the search, and is contaminated by the results
coming from with/use.

> Maybe the real solution is to use Emacs instead of GPS or Eclipse (or
> anything else)? Every time I compare the three, Emacs wins hands down on
> features that contribute to real productivity.

You know, Emacs users and us, the others, represent different species. I'm
certain that a scientific study would show that these don't even
interbreed. Each Emacs user must have been abducted by aliens in flying
saucers... (:-))

>> and it is absolutely irrelevant what is the file name of that unit.
> 
> Ok. But I can take advantage of that fact if it happens to be true.
> 
> In the above scenario, if the file names do not contain the full package
> name, I could use 'grep list *.ads', but that's less reliable, since it
> would find instances of "list" in the rest of the package spec, not just
> the package name. Building a regexp to match only package names is
> possible, but not trivial.
> 
> 
> What are some other use cases for "browsing"?

Browsing is more like looking at the list of packages to see how they are
related etc. It is a generalized view of the project. Often I don't
remember the exact name, but looking at the hierarchy of the packages I can
quickly guess it.

I have no idea how Martians (sorry, Emacs users (:-)) manage their
projects. But I cannot remember more than three phone numbers, have a
mercy! (:-))

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