From: Richard M K. <kr...@pr...> - 2008-09-04 13:21:14
|
Christophe Rhodes writes: > I prefer the approach (attached) of using a slightly non-standard > method combination, which we can now do because all CLs anyone cares > about support them. The idea is that asdf:around methods are for > internal use, and ordinary :around methods are the user-frobbable > protocol hooks. Ooh, ooh! Could we take it a bit further and allow parties between cCLan and the end-user to add more around-like methods with a partial ordering to ensure that a customizer's method gets invoked around "upstream" methods? This way, when SBCL wants to customize ASDF, and Debian wants to customize SBCL, and the site admin wants to customize Debian, and the user wants to customize the site configuration, the customizations will compose, rather than conflict? (This is one of my biggest gripes with ASDF: a fixed GF protocol and rivalrous method space leaves only the class hierarchy for customization. But while subclassing works well for system authors, it's tricky for prospective customizers to do the right thing to the class hierarchy to customize behavior for all ASDF systems the customizer wants to contribute to.) If people aren't repelled by this suggestion, I'll write something up tonight (where "tonight" is in EDT). -- Richard |