Lute Kamstra <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Lute Kamstra <[EMAIL PROTECTED]> writes: >> >>> Consider the following situation: >>> >>> function 'a is autoloaded: (autoload "blabla" ...). >>> function 'b is autoloaded: (autoload "other" ...). >>> function 'c is defined. >>> function 'd is unbound. >>> >>> "blabla" defines 'a, 'b, 'c, and 'd as functions. >>> >>> Do (require 'blabla) and then (unload-feature 'blabla). >>> >>> Currently, all four functions will be unbound by unload-feature. >>> You propose to let unload-feature restore both 'a and 'b to their >>> previous autoloads [1]. >> >> Sure. >> >>> But what should be done with 'c? >>> >>> I think restoring 'c to its previous definition would be the right >>> thing to do. >> >> Not at all. The purpose of unload-feature is to be able to restore >> a state, most particular to conserve memory. So unload-feature >> should not waste memory by keeping in effect a history of load >> sequences around. Its purpose should be confined to unloading >> those features that _can_ reasonably be unloaded. And that means >> no functions whatsoever that _redefine_ stuff. The main purpose of >> the autoload restoration is to restore autoloads into the package >> itself, not foreign autoloads. > > For me, it is most intuitive/logical that unload-feature tries to > undo the effects of loading the feature.
If it can. > It is very uncommon that a feature redefines a function (or a > variable), so keeping track of such cases will not waste much > memory. But it is very common that one loads and evals one and the same file over and over. We don't want to keep a history of that. >> I think that unload-feature should in the case of c being redefined >> simply barf and refuse to unload the feature. > > That's quite extreme. And it would require you too keep track of > redefinitions. Of the fact that they happened. That is about one cons cell worth of data. Old definitions, in contrast, can take any amount of data. > Why not use that tracking machinery to just restore these rare > cases? They don't seem exactly rare to me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
