Re: relative load-file

[Rocky Bernstein <rocky@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 5794 bytes --]

On Sun, Nov 22, 2009 at 9:29 PM, Richard Stallman <rms@gnu.org> 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.
>

[-- Attachment #2: Type: text/html, Size: 7901 bytes --]