On 20 Sep 2017, at 13:41, Anton Vodonosov wrote:
If the motivation is only this, IMHO it's a difficult approach to backward compatibility - you go online and find all usages, create pull requests, try to contact developers to have the fixes merged. If you don't find all usages (somebody's application not published online), then it will break after the change.If there is no difficulty keeping the old functions in the code base, I would leave them forever (for course deprecated).Just my opinion.18.09.2017, 00:52, "Faré" <fahree@gmail.com>:On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
I mean is it impossible to keep existing forever (implemented in terms of the new, better API)?
Some functions have a horrible API that is error-prone or misdefined
and should NOT be used by anyone when better APIs are available.
RUN-SHELL-COMMAND is a case in point — that horrible function must
die, it's a security nightmare as well as a usability absurdity.
SYSTEM-DEFINITION-PATHNAME was historically doing the wrong thing; we
provide an approximation of what it used to do in terms of supported
interfaces, but the only way to be sure that the user doesn't mean
something crazy in terms of the old meaning is to migrate to the new
interfaces.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Good girls are bad girls that never get caught.
I'm willing to do this up to a certain level. But beyond a certain point, we can't maintain code that's cluttered with stuff that we no longer understand or that does the wrong thing. If there's something really wrong, at a certain point, I will need to say "I'm the ASDF maintainer, not the Quicklisp maintainer," and be willing to break things. Particularly things that are un-maintained.
Best,
r
'