An issue that came up discussing ASDF-FLV with Didier has to do with outside modification to exported ASDF generic functions. I think it's unambiguously reasonable to say "if you mess with unexported functions, generic or otherwise, you're on your own, and could break things arbitrarily."
But I don't think ASDF has established clear expectations about extending methods of exported ASDF generic functions. I think there's been an unspoken assumption that if ASDF generic functions are to be extended, particularly by :around
, :before
, and :after
methods, there should be some novel class introduced that will be used to select extensions. So, for example, it's fine to wrap or write new methods for perform
, but not for existing component and operation classes. Doing so means that a change one might think appropriate for one's own library bleeds out into other code that one has no way of predicting, and also has the potential to collide with ASDF's own code or other people's ASDF extensions.
Those are good reasons for this convention -- no modification without introducing new classes for method dispatch -- but ASDF-FLV is an example of a system that wants to introspect about the entire running lisp image. I'd be interested in hearing what people think about this kind of case. Should we introduce, for example, an ASDF
object that extenders could add mixins to in order to enable modifications to ASDF behavior that aren't limited to a single library?
Please post any thoughts you have about this idea.