Re: Could there be a way to disable LOAD-PREFERENCES?

On 2/26/08, Gary King <[email protected]> wrote:

> I think that preferences are a general enough thing that it makes
> sense to include them in ASDF rather than reinventing the wheel
> repeatedly. That would be my argument for including them.

Ok, I think I can buy that, but... (I this has been discussed
previously, please excuse the dead horse: I only recently noticed that
SourceForge had silently set my cclan-list for no delivery. :/)

Some things I wonder about are:

* LOAD-PREFERENCES seems an odd one out at the moment, since it is a
  generic function on its own instead of being an operation used via PERFORM.
  (I'm not saying that I deeply love PERFORM, but for good and ill it is the
  way ASDF does everything else.)

* Pretty much everything else has argument order OPERATION, THING. L-P has
  THING, OPERATION.

* Especially when preference-loading is done by default via LOAD instead of
  some sort of preference file parsing, L-P is really "please inject code
  to my system at this point", which makes it me uneasy with it as a general-
  purpose mechanism.

* LOAD into COMMON-LISP seems wrong. CL-USER would be a bit better, at least.

It seems to me that 1) requiring defsystems which use preferences to
speficy that they need to be processed would not violate the pristine
source principle, and make for a saner system overall -- less places
where things can go wrong when no preference files are needed by the
system 2) allowing systems to specify the function used to preference
file would make system authors at least consider this question for a
nanosecond before they choose to use LOAD for that 3) specifying a
package where to load the preferences without writing a custom method
seems like an everyday thing to want 4) site versus user-preferences
seem to be another everyday thing to want for sites with centrally
installed stuff.

Perhaps I am just to scarred by various .magicrc files, and the
conditions when they do and don't get loaded. I definitely have not
thought about this at great depth -- just recording my goose-bumps
here.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/