On Wed, Mar 17, 2010 at 3:23 PM, Robert Goldman
<rpgoldman@sift.info> wrote:
E.g., it seems that we can fix one of Juanjo's two problems by simply
recasting one of his INPUT-FILES (?) primary method as an :AROUND method.
Around methods are a hack. If you later on decide to add an around method to ASDF then you break whatever I do. If some user decides to add an around method then it will break again.
As for the problem with TRAVERSE, I don't understand enough what the
problem is. Can it be solved simply by adding something like:
(defmethod PERFORM ((op lib-op) (c cl-source-file))
(values))
What if somebody adds another component to a system? Right now this means I have to track all existing ASDF components, know in advance which ones may form part of the module, because as it was said I am not allowed to write a method with a generic signature PERFORM ((op lib-op) (c component)) because COMPONENT is a class that ASDF defines.
Summing up, please you all consider this: if you forbid --in the ASDF specification-- to write any method that uses directly ASDF classes that means we are not allowed to extend ASDF systems at all.
* We would have to define our own system, module, component, operations, and these would no be allowed to coexist with ASDF systems.
* We would not be allowed to use the same *.asd systems that other library defines because those use ASDF's system classes.
* We would not be allowed to combine ASDF's LOAD-OP operations with our own components (precompiled files, etc) because we are not allowed to write methods using LOAD-OP and our extended classes.
Juanjo