Declaring code obsolete
fahree at gmail.com
Sat May 23 03:31:18 UTC 2015
I'm looking for hackers to review my branch obsolete-function-warnings:
In it, I add support to UIOP for issuing conditions for obsolete
functions, and use it for UIOP and ASDF deprecated functions.
They can be style-warning, warning, continuable error or error, if
possible at compile-time via a compiler-macro, or at first use at
Last option is plain error at compile-time for having failed to delete
the functions when promised.
There is also a cool but somewhat dangerous optional feature that can
automatically bumps the status of an obsolete function at every
release — you better not use it lightly.
Finally, this was the opportunity to realize that there are plenty of
offenders in Quicklisp that use long obsolete APIs of ASDF and need be
* Does it make sense to go from :style-warning to :warning to :error
to :delete ?
* Does it make sense for :error to be a continuable error, or should I
introduce an extra step for :cerror, then an :error that isn't
* Robert is in charge of the release schedule, so he should decide
what automatic bumping to use, if any. I suppose he may want
style-warning now while we're in 3.1, then warning at 3.2, then error
at 3.3, then function deleted in 3.4; except for some recently
deprecated functions that should only start issuing style-warning in
3.2, and for some backward compatibility package munging that I hope
can go away in 3.3.
* At some point soon, someone must contact all those people using
obsolete functions and classes, and chide them or offer patches.
* Now is a good time to upgrade, since all maintained implementations
at long last provide asdf3 (May 2013, so a 2 year delay from release
to ubiquity; let's hope 3.1 will be ubiquitous next year).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"To speak algebraically, Mr. M. is execrable, but Mr. G. is (x+1)ecrable."
— Edgar Alan Poe
More information about the asdf-devel