[armedbear-devel] RFC: Autoloading and "multi-homed symbols"
ehuels at gmail.com
Wed Aug 1 12:14:13 UTC 2012
Just committed my progress on the automatically generated autoloads. The
next step is to clean up "autoloads.lisp" (the file which still exists to
allow manual addition/manipulation.
While I can do that step by myself, I'd like to discuss a problem we
already have today, just never encountered:
Generic functions can have methods defined in more than one file. Example:
PRINT-OBJECT has its GF defined in print-object.lisp, but has methods
defined in print-object.lisp, java.lisp and format.lisp. Clearly, when
PRINT-OBJECT is being called for the first time (and hence needs to be
autoloaded), it's not correct to autoload java.lisp or format.lisp: we
would miss the generic function and if print-object.lisp is loaded later,
it'll overwrite the methods already defined.
On the other hand, *only* loading print-object.lisp isn't correct either:
we have no idea if the arguments passed to the call should have caused the
methods in java.lisp or format.lisp to be triggered.
My current thinking about the above is that we'd need to load all files in
which methods are being defined for PRINT-OBJECT. These files should makes
sure (through REQUIRE) that they load the file with the generic function
first. The autoloading facility should then hook into require in some way
or another to make sure it doesn't load files which have been loaded
through REQUIRE to prevent out-of-order loading.
Then my next issue is that if one of the files being loaded in the loaded
group has symbols which are multi-homed in a different (but overlapping)
set of files, those files need to be loaded as well, for the same reasons.
My question is: what are your thoughts on the subject?
BTW: I have some more questions I'd like to discuss regarding autoloading,
but since they are unrelated, I'm holding off posting until discussion on
this subject has settled on a general direction for development.
What was autoloading again? Autoloading is a mechanism which allows ABCL to
start up quickly by deferring loading of FASLs which it only needs later.
Also, helps ABCL to run in memory-restrained environments by loading only
the support necessary to run the code at hand. Autoloading is a feature
used *only* for ABCL's own FASLs. User-FASLs will always be fully loaded
(although I suppose it should be possible to leverage the existing
autoloader infrastructure to help users who think they need this for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel