On Sun, Nov 15, 2009 at 5:38 PM, Richard Stallman <address@hidden>
So what require-relative and load-relative allow one to do is create theseI do not follow your point. I think I understand what you mean by a
little independent units without the overhead of using a more elaborate
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 asWhy do you think that making it relative to the location of the loading
the C preprocessor __FILE__.
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.