On Sun, Nov 22, 2009 at 9:29 PM, Richard Stallman
<address@hidden> wrote:
First, it seems like a little more work that isn't strictly needed - adding
that file.
That is one file in your entire program, which we assume is so many
files that you have decided to split it into multiple directories.
It is negligible work.
Yes, but it is still more work. I believe that declaring that this file/module belongs to some specific package makes things worse for the programmer in terms of agility and free software.
Why? Let's go back to the compiler project which has sub-part parser and code generator. Initially, I have directories for the parser and code generator parts, while compiler has some top-level glue routines like compile-file and build-project. The language for my compiler is wildly successful and so now people request to use the parser part without the other stuff.
Ok. So now I want to turn that sub-part into its own project. If I were clairvoyant, I might have realized this in the beginning and made parser as its own project inside compiler. But not code generator, because no one is going to ask about that and it looks like it is additional work to note top-level sub-parts. If however I make compiler a sub-project, from the internal-loading standpoint I have to constrain myself to stay inside the parser subdirectory. There may be other utility programs in the compiler that I want to use that I haven't externalized yet. For example, perhaps it is "load-relative".
So how in the scheme you propose do I handle this? Is this adding more overhead compared to load-relative? If so, it is less agile.
But I also wrote that this is also bad from a standpoint of Free Software. Why? Because I want to encourage others to use parts of my program, extend and modify it. If I have declared in the file that this file/module belongs to a specific package, then that is something everyone who wants to use that part will have to change when they adapt for their use, but might not under the scheme I propose.
Second, as files move over the course of the lifetime of a project, this
scheme will *always* require changing files more often than what I proposed
. Here is an example based on experience so far.
With file-relative references, any time you move one file,
you have to change all its references to other files,
as well as all other files' references to it.
For other files' references to it, yes. Not exactly true for its references to other files. See below.
With main-directory-relative references, when you move a file
between subdirectories, you don't have to change its references
to other files. You only change the way other files refer to it.
And that's sometimes true with file-relative references. If I move a file from
top/part/a.el to top/another-part/a.el and "a.el" only refers to things above "part"
-- that is the references all start out ".." -- then there is no change.
Thus, when moving one file, the main-directory-relative approach
always requires less change.
Not true. See above. I'm not sure how one assess the value of simplifying moving one file versus renaming a directory or moving a collection of related files.
You present a scenario of moving many files together. Indeed, in that
scenario, the file-relative approach avoids the need to change the way
these files refer to each other.
And why that is likely to occur is that we agree that modular programs are made of subparts which are in turn made of other subparts. The names of the subparts and the locations within the project may change, but the relative position will probably change less.
But it still requires changing the
way they refer to all other files.
In some cases, yes. But in some cases no - such as renaming a directory which has components which are not referred to outside the directory/subpart.
In my compiler example, I said I had top-level utility programs to compile a file or build a project. If I push those programs down into a directory say "utility" then yes, I have to change references. And under the scheme you propose I wouldn't. However if later I decide to change split "utility" into two directories at the same level under compilers, say "command-line" and "gui", then no I don't have to change anything. Again, I am assuming here that there are no references into "command-line" or "gui" from say "parser" or "code-generator" and that files inside "command-line" refer only to other "command-line" files not the "gui" files or vice versa. But I think these are reasonable and common situations. At any rate, this has been my experience so far.
I can't fully follow your scenario because
For now, I find it convenient to split the parts of the Ruby
debugger *rbdgr* into several of files: *rbdbgr-core*, *rbdbgr-track-mode*and
*rbdbgr*
I don't understand the significance of the *'s. Do you write *'s in
file names, or are they wildcards, or what?
Sorry. My mistake. *x* was supposed to indicate a name of
a file in italic font. See
http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00940.html
which seems to show this. However, since this is a mailing list, in the
future I'll use quotes for file names, like have have above.
Although I didn't intend wildcards, now that you mention it that's a good thing to add to the load-relative package. For example, right now I have an "init" directory which contains initialization code for each of the debuggers that the debugger front-end supports. Right now I have "do-list" to load each of those. Better though would be to put the looping inside the load-relative package.
Emacs convention is not to use *'s in any names, except for names
of special buffers.