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

Richard M Kreuter wrote:
> "Nikodemus Siivola" <[email protected]> writes:
> 
>> 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 didn't mean to start a thread about the goodness of
> LOAD-PREFERENCES, but I agree with all of Nikodemus's concerns.
> 
> IMO, it would have been better if preference loading functionality had
> been associated with a subclass of SYSTEM (and probably not available
> at the granularity of COMPONENT, either), so that authors could decide
> whether to support customization.  (And even when an author doesn't
> support customization, a user who wants to roll his own customization
> can add an :AFTER method with an EQL-specializer, too.)
> 

This approach seems good to me.  However, I would suggest that ASDF
*provide* the subclass of system in question, together with a
specification of the expected, default behavior.  I would suggest this
because of experiences with test-op.  Having a placeholder there,
without behavior expectations has not worked out terribly well (e.g., it
was just put in without guidance to test-op implementors about what a
test result would be, whether it should be returned, printed, etc.).

Would it be possible to extend the :in-order-to framework to make this
work through perform?

That said, I confess that I have a not-so-happy feeling about this
because of my experiences trying to make the test-op work.  Extending
operations seems to not work so well in ASDF....

Best,
R




-------------------------------------------------------------------------
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/