Re: Add Deprecated aspect to Ada 2020

Re: Add Deprecated aspect to Ada 2020

[Simon Clubley]

On 2017-08-19, Lucretia <laguest9000@googlemail.com> wrote:
> Hi,
>
> I'm sure plenty of people have libs where certain parts have been deprecated over time. It would be a nice addition to have an aspect to say this and emit a custom warning when it's used.
>
>    function A return B with
>      Deprecated => "Will be removed in version x.y.z, please use C instead.";

You may want to re-think the wording of that example text. :-)

[Sorry, but I couldn't resist. :-)]

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Add Deprecated aspect to Ada 2020

[Lucretia]

Hi,

I'm sure plenty of people have libs where certain parts have been deprecated over time. It would be a nice addition to have an aspect to say this and emit a custom warning when it's used.

   function A return B with
     Deprecated => "Will be removed in version x.y.z, please use C instead.";

Re: Add Deprecated aspect to Ada 2020

[Björn Lundin]

On 2017-08-19 20:52, Lucretia wrote:
> Hi,
> 
> I'm sure plenty of people have libs where certain parts have been deprecated over time. It would be a nice addition to have an aspect to say this and emit a custom warning when it's used.
> 
>    function A return B with
>      Deprecated => "Will be removed in version x.y.z, please use C instead.";
> 

Its called Obsolescent in Ada

-- 
--
Björn

Re: Add Deprecated aspect to Ada 2020

[Dmitry A. Kazakov]

On 2017-08-19 20:52, Lucretia wrote:

> I'm sure plenty of people have libs where certain parts have been deprecated over time.

Yes. Gtk is full of this mess.

> It would be a nice addition to have an aspect to say this and emit a
> custom warning when it's used >
>     function A return B with
>       Deprecated => "Will be removed in version x.y.z, please use C instead.";

Why should anybody need to remove an interface function?

Or to put it differently. Let there be a reason why a call to some 
function is not desired. Then the reason must be spelled in the language 
terms. E.g. this:

    variable value is used before being initialized

and not this:

    initialization of this variable will be removed in the next version, 
don't use it ever!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Add Deprecated aspect to Ada 2020

[Jacob Sparre Andersen]

Björn Lundin wrote:

> Its called Obsolescent in Ada

And GNAT already has it.

It is useful, if you figure out that an API has to change, but you want
to give the users of the API some time - and useful help - to adapt
their usage of the API.

I've been putting quite a few Obsolescent aspects into a package
specification this week as a part of the simplification of the
implementation of the package.

Greetings,

Jacob
-- 
"The generation of random numbers is too important to be left to chance"

Re: Add Deprecated aspect to Ada 2020

[Per Sandberg]

Well.

Initially this is not a problem but i have quite often seen this 
requirement as libraries evolves over time. Its good to use to maintain 
backward compatibility while notifying the users that they should change 
their code prior to stepping version of that particular library.

/P



Den 2017-08-19 kl. 21:34, skrev Dmitry A. Kazakov:
> On 2017-08-19 20:52, Lucretia wrote:
> 
>> I'm sure plenty of people have libs where certain parts have been 
>> deprecated over time.
> 
> Yes. Gtk is full of this mess.
> 
>> It would be a nice addition to have an aspect to say this and emit a
>> custom warning when it's used >
>>     function A return B with
>>       Deprecated => "Will be removed in version x.y.z, please use C 
>> instead.";
> 
> Why should anybody need to remove an interface function?
> 
> Or to put it differently. Let there be a reason why a call to some 
> function is not desired. Then the reason must be spelled in the language 
> terms. E.g. this:
> 
>     variable value is used before being initialized
> 
> and not this:
> 
>     initialization of this variable will be removed in the next version, 
> don't use it ever!
> 

Re: Add Deprecated aspect to Ada 2020

[Dmitry A. Kazakov]

On 2017-08-21 21:09, Per Sandberg wrote:

> Its good to use to maintain 
> backward compatibility while notifying the users that they should change 
> their code prior to stepping version of that particular library.

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.

You always can add new defaulted parameters, new subprograms, new 
packages without removing old ones. Even cases like rolling up security 
do not justify removal. You can always add backward compatible insecure 
mode.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Add Deprecated aspect to Ada 2020

[J-P. Rosen]

Le 21/08/2017 à 21:34, Dmitry A. Kazakov a écrit :
> You always can add new defaulted parameters
This can break compatibility if the old subprogram is used in an
instantiation as an actual for a generic formal subprogram parameter

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Add Deprecated aspect to Ada 2020

[Dmitry A. Kazakov]

On 22/08/2017 07:47, J-P. Rosen wrote:
> Le 21/08/2017 à 21:34, Dmitry A. Kazakov a écrit :
>> You always can add new defaulted parameters
> This can break compatibility if the old subprogram is used in an
> instantiation as an actual for a generic formal subprogram parameter

Possibly, although I don't care much about generics, if anybody wants to 
improve something then maybe this rather than adding a useless aspect?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Add Deprecated aspect to Ada 2020

[Luke A. Guest]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 22/08/2017 07:47, J-P. Rosen wrote:
>> Le 21/08/2017 à 21:34, Dmitry A. Kazakov a écrit :
>>> You always can add new defaulted parameters
>> This can break compatibility if the old subprogram is used in an
>> instantiation as an actual for a generic formal subprogram parameter
> 
> Possibly, although I don't care much about generics, if anybody wants to 
> improve something then maybe this rather than adding a useless aspect?
> 

It wouldn't be useless. What's useless is keeping old, possibly broken,
functionality in an api, thus increasing the size of the whole library.
Which is what you're proposing. That's useless.

Re: Add Deprecated aspect to Ada 2020

[Pascal Obry]

Le mardi 22 août 2017 à 20:32 +0100, Luke A.Guest a écrit :
> It wouldn't be useless. What's useless is keeping old, possibly
> broken,
> functionality in an api, thus increasing the size of the whole
> library.
> Which is what you're proposing. That's useless.

Agreed, over time it makes the library hard to use as it contains a
pile of junk routines.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Add Deprecated aspect to Ada 2020

[Dmitry A. Kazakov]

On 22/08/2017 21:32, Luke A. Guest wrote:

> It wouldn't be useless. What's useless is keeping old, possibly broken,
> functionality in an api, thus increasing the size of the whole library.
> Which is what you're proposing. That's useless.

I.e. instead of fixing bugs and making functionality straight we better 
add new bugs and new broken functionality? Sounds familiar...

Anyway, you could add At_Use, At_Call, At_Access, At_Instantiation instead:

    procedure Foo (X : T)
       with At_Call => "Hey, only idiots would call this ever!";

Not much fun without static subprograms, though...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Add Deprecated aspect to Ada 2020

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:onfcjn$utn$1@gioia.aioe.org...
> On 2017-08-21 21:09, Per Sandberg wrote:
>
>> Its good to use to maintain backward compatibility while notifying the 
>> users that they should change their code prior to stepping version of 
>> that particular library.
>
> 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.)

> You always can add new defaulted parameters, new subprograms, new packages 
> without removing old ones. Even cases like rolling up security do not 
> justify removal. You can always add backward compatible insecure mode.

Exactly. (Although the security case might be a justitification for an 
incompatibility. But in that case it would be done immediately - no waiting 
period.)

                             Randy.

Re: Add Deprecated aspect to Ada 2020

[Lucretia]

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.

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.

Re: Add Deprecated aspect to Ada 2020

[Randy Brukardt]

"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.