[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Robert P. Goldman]

Faré wrote:
> 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)'
> ~/quicklisp/dists/quicklisp/software/**/*.{asd,lisp})
> 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
> mailing-list.

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! ;-)

cheers,
r