Re: organizing deep source trees with child packages

[Stephen Leake <stephen_leake@stephe-leake.org>]

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

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

You seem to be deliberately misrepresenting the question. No one is
talking about the absolute path as "the file name"; we are only talking
about the part of the path that maps to the Ada package name.

So far, the choices seem to be:

package name        Foo.Bar.Baz
gnat convention     foo-bar-baz.ads
"java"              foo/bar/baz.ads
gnatkr              f-barbaz.ads
something else      fobaba.ads
    
Which of these is best, and why? 

I vote for the gnat convention, because the mapping is trivial, and
directories are a pain.

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

If the same packages were implemented without generics, there would be
the same number of files (minus the actual generic files). I don't see
that as a significant issue in this discussion.

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

Why is it necessary to _remember_ that? What does this have to do with
file names? Unless you are attempting to encode all of that information
in the file name and/or the package name, you are just confusing things
by bringing this into the discussion.

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

Yes, I agree; that's why I have only a few directories, each with
hundreds of files.
>
>>> 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.

Still not specific enough. What demands do the various activities place
on the browser?

I do that all day, and never feel the need for anything more than the
Emacs file browser, together with Emacs Ada mode navigation, gives me.
Which means I'm either "looking for a file" in the file browser, or
"finding the spec/body for this identifier".

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

So the Emacs file browser is more efficient for this task. I find it
more efficient for all tasks :).

>> 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... (:-))

Yes, it often seems that way.

That doesn't mean we can't have a technical discussion, to understand
what the issues are, and how to improve both Emacs and GPS to make them
both better.

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

File names give very little information on that. 

I don't think I learned anything from this message.

-- 
-- Stephe