On Wed, Mar 17, 2010 at 3:23 PM, Robert Goldman <[email protected]> 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 -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
_______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
