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.