On 15 March 2010 10:56, james anderson james.anderson@setf.de wrote:
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.
I see multiple problems with this approach: * In terms of API, it seems to make things less modular rather than more, with plenty of "interesting" inheritance issues. * Also, the knowledge of what needs to be translated or not is often in the operation, not the component. * In practical terms, the reading and normalization of output translation specifications is expensive enough that I don't want to have to do it for every component or something.
I frankly prefer Juanjo's proposed API, which seems more modular, and lets you specialize on either operation or component (but most likely operation).
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] We have four boxes with which to defend our freedom: the soap box, the ballot box, the jury box, and the cartridge box. — Attributed to Representative Larry P. McDonald (D), 1935-1983