Re: organizing deep source trees with child packages

On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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.

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

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. 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. Parent's name <-> directory name. Child name <->
file name.

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. Especially when
you have hundreds of generic package instances popping everywhere. Pushing
files into different directories makes things only worse. The point is,
when browsing a project you are not interested in files, you are looking
for Ada units, and it is absolutely irrelevant what is the file name of
that unit. 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.

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

Relevant Pages

  • Re: organizing deep source trees with child packages
    ... It should rather show simple names of Ada units, ... but I assume it has a package browser that shows this ... If I'm _searching_ for an Ada unit that deals with lists, ...
    (comp.lang.ada)
  • Re: organizing deep source trees with child packages
    ... This is not a matter of semantic, this is a matter of being handy for ... A file system browser allows viewing files by file name; ... A package browser allows browsing ... browser as a package browser, avoiding the work of maintaining two ...
    (comp.lang.ada)
  • Re: New packages
    ... so if it's just a matter of getting this one ... > program packaged it would be easier to file an RFP and see if any ... > existing developers are interested in picking up the package. ... Do I need to submit a new ITP? ...
    (Debian-User)
  • Re: Fedora disimprovements: am I alone?
    ... enough sense to try running system-config-services before jumping to any ... of them from Gnome to XFCE and still have various Gnome stuph on them. ... it does not matter which package is default for which DE ...
    (Fedora)
  • Re: Nestle Semi-Sweet Morsels Shrinking
    ... Today's mighty oak is just yesterday's nut that held its ground. ... the package isn't that big a deal. ... doesn't matter because we put in as much as we want. ...
    (rec.food.cooking)