On 24 Jan 2014, at 19:56, Robert P. Goldman rpgoldman@sift.info wrote:
Pascal Costanza wrote:
The new ASDF will break systems that subclass OPERATION. Those libraries' maintainers will have to look at their code, based on the error message, and see what needs to be done. For the vast majority of them, five minutes work will suffice. For those that take more... well, as you point out, the bug fix had to be made, and I stand ready to help those who need assistance adjusting.
It's good to signal an error or a warning for this case.
It would have been better if asdf:operation would have kept its old semantics, maybe with a deprecation warning when it's used, and that the new semantics would have been provided by, say, asdf3:operation. People who see the warning and care about keeping things up to date could react to the warning and move from asdf:operation to asdf3:operation, which is not much more work than what is necessary now. People who care less (maybe because other things are more important - asdf is not the center of the universe after all) would not need worry, because everything would work as before, even in a setting where both asdf2 and asdf3 semantics would be needed side by side.
I believe that the issue was that Faré couldn't preserve both:
- OPERATION is the universal superclass so that methods on it could do
things like introspection, collect statistics, etc. and
- OPERATION provides a certain expected set of behaviors to those who
wish to provide their own subclasses.
He had to choose one or the other, so he chose 1, and sacrificed 2. He has successfully convinced me, at least, that he couldn't do both.
This suggests as a lesson for the future that one might wish to always distinguish between class FOO and class FOO-EXTENSION where the library user is to subclass only FOO-EXTENSION (but may, for special cases, define methods on FOO).
This is what the CLOS MOP already does (object -> standard-object, class -> standard-class, method -> standard-method, etc.).
Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.