Re: relative load-file

[Rocky Bernstein <rocky@gnu.org>]

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

On Sun, Nov 15, 2009 at 5:38 PM, Richard Stallman <rms@gnu.org> 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.

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