[asdf-devel] Pushed version 22.214.171.124 -- first version with checks for OPERATION subclasses -- please test!
Robert P. Goldman
rpgoldman at sift.info
Wed Jan 22 21:05:27 UTC 2014
> On Wed, Jan 22, 2014 at 2:54 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
>> I think what Faré is pointing out is that one could build, for example,
>> an introspection library by adding for example, PERFORM methods that
>> would dispatch on OPERATION and that would catch *all* PERFORMS and
>> write a log or something like that.
>> If we no longer make OPERATION the root of the hierarchy then such
>> introspection libraries will no longer work.
> I was more thinking about people defining methods on operation.
I *think* we were trying to say the same thing. Maybe not? I was
giving PERFORM as an example of a generic function on which we could
define methods for the OPERATION type.
I don't know what sorts of code would do that: introspection seemed like
a logical example.
Are we talking about something different?
> less -p 'defmethod.* operation)' $(grep -il 'defmethod.* operation)'
> Reveals 9 files beside copies of ASDF that define methods on operation.
> Some of them may or may not be affected in practice by making
> operation not the root of the hierarchy.
> POIU also does it, though if you change the base class incompatibly, I
> can update POIU.
> ITA's QRes also defines methods on operation (as you can see in the
> parts that were open sourced); maybe other proprietary systems do,
> too. Once again, if anyone is extending ASDF in proprietary system (or
> just ones not on quicklisp), he'd be well-advised to be on this
Maybe that's true, but we have no way of enforcing it. Hell, we don't
even have the means to *suggest* it -- the Catch-22 is that we can only
suggest subscribing to ASDF-devel... on ASDF-devel! ;-)
More information about the asdf-devel