Faré wrote:
But we don't invite programmers to redefine methods for existing classes, or at their own risk.
Why would these particular functions be special and require that there be a blank slate for :around methods?
I guess what seems funny about OUTPUT-FILES is that the main methods have a return type that is *different* from the return type of the generic function.
The main method should return two values:
1. A set of pathnames 2. A boolean that indicates whether the :AROUND method should translate the pathnames.
Then the :AROUND method translates this so that only a single value -- a set of possibly-translated pathnames -- is returned.
This strikes me as odd: what would you describe the signature of OUTPUT-FILES as being?
So neatness might argue that there be a POSSIBLY-TRANSLATED-OUTPUT-FILES (with a better name, of course), and an OUTPUT-FILES (behaving as now), with the former calling the latter, and each having a simpler signature.
That said, I don't see the need to break code for neatness.
As for "why these particular functions?" it's because (a) they are exported and (b) we have invited programmers to define new methods for them. Doing (b) correctly arguably requires more understanding if you have to know that there are existing :AROUND methods whose behavior must be preserved. If the :AROUND method was refactored to the previously proposed P-T-O-F, the extending programmer's job would be simpler. That said, the existing contract for methods is simple enough that I'm not going to worry about it.
I'm going to drop this into my email archive as "interesting, but unimportant." I can return to it someday when tidying up unbroken code is the only thing I worry about, i.e., never.
As for "actual extension points," I have occasionally added new methods for these generic functions, but only simple ones. The only case I can think of that might be a problem with the existing contract would be one where there are multiple output-files, but only some of them are to be translated.
To date, I have never written an extension that had > 1 output-file, much less one that sent them to different places, so this is only a hypothetical. Perhaps an operation that built some data structure and an index.... But I can't see why those would go in different directories.
Thanks for the explanation, r