Re: Add Deprecated aspect to Ada 2020

["Randy Brukardt" <randy@rrsoftware.com>]

"Lucretia" <laguest9000@googlemail.com> 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.