Re: organizing deep source trees with child packages

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

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

> On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duchêne (Hibou57) wrote:
>>>
>>>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
>>>> <ludovic@ludovic-brenta.org> a écrit:
>>>>> Directories are *not* a solution for these problems.  They do not
>>>>> represent dependencies or hide any information from the compiler.
>>>> This is not a matter of semantic, this is a matter of being handy for  
>>>> human beings.
>>>
>>> Actually long file names is not the problem. The problem is that GPS in its
>>> tree view control used for browsing the project units ignores the packages
>>> hierarchy in favor of the hierarchy of the file system. Change that in GPS
>>> (or another Ada IDE) and the problem would largely disappear.
>> 
>> I still don't understand what "problem" is being solved here.
>
> 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?

> GPS project view shows file names, e.g.:
>
> gtk-layered-waveform-ring_data_buffer.adb
> gtk-layered-waveform-ring_data_buffer.ads
>
> It should rather show simple names of Ada units, e.g.:
>
> gtk
> |-layered
> |   |-waveform
> |   |   |-ring_data_buffer
> |   |   |   |-package specification
> |   |   |   |-package body

I don't use GPS, but I assume it has a package browser that shows this
tree. Personally, I've never felt the need for such a view.

I guess you are saying "yes, long package names are hard to read, and
this tree view is a solution to that".

>> A file system browser allows viewing files by file name; that's a good
>> solution for a class of problems. A package browser allows browsing
>> packages by package name; that's a good solution for another class of
>> problems.
>> 
>> If the file and package names are the same, then you can use a file
>> browser as a package browser, avoiding the work of maintaining two
>> tools.
>> 
>> When do file names and package names _need_ to be different?
>
> Always. 

Why? Simple assertions don't get us anywhere.

> Actually this is what the OP wished to have: a correspondence between
> fully qualified names of Ada units and paths of the files containing
> these units. 

The current gnat convention gives that.

> Parent's name <-> directory name. Child name <-> file name.

That's another alternative, with the drawbacks several of us have
pointed out.

>> I don't see any problem with long file names; they used to be a problem
>> on 80 character terminals, but we are past that now.
>
> For projects of many hundred files, it is a huge problem. 

Not for me or Ludovic (or many others, I assume). Exactly what is the
problem?

> Especially when you have hundreds of generic package instances popping
> everywhere. 

Why are generics a special case? 

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

> Pushing files into different directories makes things only worse. 

How, exactly?

> The point is, when browsing a project you are not interested in files,

Depends on exactly why I'm "browsing".

> 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?) But since the Emacs file
browser already provides this, I see no need to spend additional
resources adding that specific capability.

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.

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

> In fact, if the source control systems were not so retarded, we would
> have no files at all, just versions of units stored in a database.

Many people have said that over the years, and Rational (I think) built
a system that worked that way. It was a failure, and I'm not aware of
any other system that actually works that way. 

The reason is the flexibility, power, and reliability of the current
file based system. You'll have to make _very_ solid arguments to counter
that. So far I see only vague unsubstantiated assertions.

-- 
-- Stephe