From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Add Deprecated aspect to Ada 2020 Date: Thu, 31 Aug 2017 19:13:12 -0500 Organization: JSA Research & Innovation Message-ID: References: <11fa58ea-fa48-4cc3-861d-c55df76c9e6b@googlegroups.com> Injection-Date: Fri, 1 Sep 2017 00:13:14 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="6643"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47868 Date: 2017-08-31T19:13:12-05:00 List-Id: "Lucretia" wrote in message news:11fa58ea-fa48-4cc3-861d-c55df76c9e6b@googlegroups.com... > On Thursday, 31 August 2017 02:05:18 UTC+1, Randy Brukardt wrote: > >> > I disagree. >> > >> > If backward compatibility can be maintained there is no reason to >> > remove >> > the functionality. "Make it look better" does not count as one. >> > >> > If compatibility cannot be maintained, there is nothing to warn about, >> > you >> > just fix the bug before next release. >> >> Yup. This is the exact policy that we apply to Claw. One never makes an >> incompatibility that you don't have to, and that includes supporting old >> interfaces essentially forever. Perhaps the documentation and/or comments >> will suggest that new code not use the subprogram, but that's as far as >> we'd >> go. (There's no way to prove no one still uses a particular subprogram, >> after all, unless the entire system is in-house only.) > > No wonder software and OSes are so bloated when there are people like you > who don't prune the old crap that needs to go. There almost always is no such thing. The vast majority of "improvements" are only in the eye of the person who invented them, so in most case the best thing to do is to not change it in the first place. (I say this from experience, having built many "improvements" over the years that ended up simplifying nothing, just forcing a lot of work.) The situation is somewhat different with captive code (say, the Janus/Ada compiler); one can check all of the uses and determine that no uses of the old code exist (or make changes to make that true). Then it is important to get rid of old, dead code. > You put in the deprecated aspect, this is the warning to users, if they > don't adhere > and change their code, they're in for a, known, surprise when that's gone. That's stupid. In the case where an incompatiblity is required, you *immediately* make the change and document the appropriate changes. Otherwise, you have change the documentation and code twice, doubling work. If it is truely a good idea, there is no reason to wait (it's incompatible anyway), and users are going to have to change sooner or later, it might as well be sooner. (Indeed, in the vast majority of cases, that is the only option, since the routine in question has to be changed -- replacement is rarely a realistic option.) Otherwise, you're supporting old stuff that you want to get rid of, and you very well could end up encouraging people like me to put off changes to the last minute -- which will cause problems for everyone. Randy.