Faré wrote:
On Wed, Jan 22, 2014 at 2:54 PM, Robert P. Goldman rpgoldman@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