good afternoon;
this does not sound like a case for specialization. it sounds more like delegation. what about hooking an output translator into the components. if it is there, it is used. if it is not, no translation happens. (as much as i may regret this) the "standard" output translation is supplied as the default initform / or default initarg. if one supplied nil in the initialization form, that is used instead and no translation happens.
On 2010-03-15, at 16:47 , Faré wrote:
Dear Juanjo,
Indeed. This or any other way that does not break current ASDF. What I would like is seamless integration without imposing something that is prone to break in the future. Another possibility would be for OUTPUT-FILES to return two values: the list and an optional second value saying "do not translate!" This second value will be ignored by existing functions but it may be used by apply-output-translations It also has the advantage that the main output value remains in the same format and we do not introduce a corner case that might break ASDF's logic.
Your API sounds great. What about this?
(defmethod output-files :around ((op operation) (c component)) "Translate output files, unless asked not to" (multiple-value-bind (files fixedp) (call-next-method) (if fixedp files (mapcar #'apply-output-translations files))))
If you're OK with it, I'll push it as ASDF 1.635.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http:// fare.tunes.org ] Faré's Second Law of Dissent: I am Right, whence it follows that all who disagree with me are either (1) evil, (2) stupid or (3) crazy. (The alternatives are not mutually exclusive.) This universal law is valid for all values of "me", including "you".
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel