On 3/17/10 Mar 17 -3:31 PM, Juan Jose Garcia-Ripoll wrote:
On Wed, Mar 17, 2010 at 3:23 PM, Robert Goldman <rpgoldman@sift.info mailto: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.
For the record, I don't agree that :around methods are a hack. Or at any rate, no worse than (call-next-method). If you don't like CLOS, you won't like ASDF. ASDF was explicitly designed to be a successor to MK-DEFSYSTEM that exploited CLOS.
I /do/ agree that we need to layer the protocol more. We had already had a layer that allowed us to separate ASDF internal around methods from ASDF user around methods. This was removed over my protests.
It seems reasonable to me that we might want to identify an API layer that is explicitly for people adapting ASDF to particular Lisp implementations. I would welcome suggestions for improving this.
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.
The inclusion of LIB-OP should open up
(defmethod PERFORM ((op LIB-OP) (c COMPONENT)) ...)
to you.
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.
I think the above is overboard. It would be more helpful for you to work to provide a clean description of what is an acceptable API and what is not than to indulge in this kind of overstatement.
We cannot allow people to write arbitrary methods on arbitrary bits of ASDF --- the whole system would become unstable and unmaintainable. So we MUST find a crisp way to characterize what extenders can and can't do.
Please focus your attention on helping us define a clear set of guidelines rather than attacking the notion of limitations on the extenders.
Robert