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,
remake,
pydbgr,
rbdbgr, etc.). For now, I find it convenient to split the parts of the Ruby debugger
rbdgr into several of files:
rbdbgr-core,
rbdbgr-track-mode and
rbdbgr.
rbdbgr requires
rbdbgr-track-mode and
rbdbgr-core.
rbdbgr-track-mode requires
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 and
rbdbgr-track-mode 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 string.
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
(file-name-nondirectory (__FILE__))))))