[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: relative load-file

From: Rocky Bernstein
Subject: Re: relative load-file
Date: Sun, 15 Nov 2009 18:50:16 -0500

On Sun, Nov 15, 2009 at 5:38 PM, Richard Stallman <address@hidden> wrote:
   So what require-relative and load-relative allow one to do is create these
   little independent units without the overhead of using a more elaborate
   packaging systems.

I do not follow your point.  I think I understand what you mean by a
program with subparts.  Can you explain why you think
`require-relative' is particularly helpful for that?

Particularly helpful? Let's just go with helpful. ;-)

require-relative allows me to load or eval and test any one of the subparts without mucking with the load path yet ensure I am getting the right files loaded.

One can do something similar by saving, modifying and restoring load-path. I've done that in many languages for many years. And after all these years it is still clumsy, cumbersome, and fragile.

(In require-relative, after the check for a feature, if the feature is loaded an additional check can be done to see if the source location is the same as the location requested)

Others have noticed issues with path-searching mechanisms; so programming languages like Ruby, Scala, and Python have been moving in the direction of a something like require-relative even though they've long had something like load-path.

   That's in fact what I have done<http://github.com/rocky/emacs-load-relative>.
   The only "primitive" needed is Ruby's __FILE__  which is the same thing as
   the C preprocessor  __FILE__.

Why do you think that making it relative to the location of the loading
file is particularly necessary?

Again let's drop the "particularly" part. No doubt there are many ways to do things and I don't represent that this is the only to work. Possibly not the best way either, although I think an improvement for me over what I've seen codified so far.

When I create source code, I very well know what the relative directory/file structure looks like. So when I want to load or require another module, using the relative name is petty simple, straightforward, and clear. Irrelevant is what the load-path or current directory might be is set to at run-time. The only information Emacs needs to fill in is the directory of the source code.

That said, I suspect there are other situations that a macro-expanded __FILE__ would be useful.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]