I don't think it as good for a couple of reasons.
First, it seems like a little more work that isn't strictly needed - adding that file.
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.
I am working on a debugger front end
package for GNU Emacs. Some files are specific to specific debuggers (bashdb
, etc.). For now, I find it convenient to split the parts of the Ruby debugger rbdgr
into several of files: rbdbgr-core
. Initially life was good. But then as I started adding more code and more debuggers, I wanted to have Ruby debugger code in a separate Ruby folder.
With the scheme I am currently using, I don't have to change the requires when they stay the same relative to other required files: rbdbgr
still requires rbdbgr-core
which were located in the same directory and continue to be so. Irrelevant is how they are accessed from the top. But the scheme you propose, I think I would have had to change the require
Right now, I am planning on putting code for a second debugger ruby-debug
in the Ruby directory. Given this change, perhaps I want a directory for each debugger. Perhaps that is off of the top-level, or perhaps this is another directory underneath Ruby. Again with the scheme I currently use, there are fewer changes which makes it easier for me to try out the various possibilities.
If there is a __FILE__ variable/macro/function, implementing what I propose is very simple. Aside from lingering the bugs that I will discover and fix over time, what I want is done.
But here's another neat thing that I just realized one can do using __FILE__ (or an extended load-file-name if you prefer). I've just added that to the load-relative package
Rather than use: (provide 'feature-name
), via __FILE__ one can write a provide-me
macro that allows you to omit having to give the feature name if it is the same as the file's base name sans directory. (Personally, I think using this file/feature naming convention is generally a good idea). The macro is short and simple. So here it is:
(defmacro provide-me () "Call `provide' with the feature's symbol name made from
the source-code's file basename sans extension. For example if you
write (provide-me) inside file ~/lisp/foo.el, this is the same as
writing: (provide 'foo)." `(provide (intern (file-name-sans-extension