• bearophile (8/8) Mar 08 2011 I don't know much about Scala language, so I've found this small funny t...
• spir (16/22) Mar 08 2011 I read 2-3 times Walter thinks warnings are bad. Things are either corre...
• Jim (3/27) Mar 08 2011 Yes, you could very well argue that the user's code is correct for the v...
• spir (10/37) Mar 08 2011 I did not mean anything like that at all, I guess. (Or do /I/ misunderst...
• Jim (3/40) Mar 08 2011 I think that a program P written for version X of the compiler should no...
• renoX (6/6) Mar 08 2011 This 'deprecated' assertion is not about *language* changes but about
• bearophile (6/7) Mar 08 2011 D compiler has the "-d" switch that allows deprecated features.
• Jonathan M Davis (32/42) Mar 08 2011 The workflow with regards to deprecating something in Phobos is to initi...

bearophile <bearophileHUGS lycos.com> writes:

I don't know much about Scala language, so I've found this small funny thing in
the Lambda the Ultimate blog. In Scala parameter names can be deprecated:

def somefunction( deprecatedName('x) y: Int) = ...

This gives deprecation warning to callers using the parameter name x.


More info. In Scala annotations are user-defined, I presume, have methods, etc.:

http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/deprecatedName.html

This helps against one of the problems Don has with named arguments.

Bye,
bearophile

spir <denis.spir gmail.com> writes:

On 03/08/2011 09:29 AM, bearophile wrote:
 I don't know much about Scala language, so I've found this small funny thing
in the Lambda the Ultimate blog. In Scala parameter names can be deprecated:

 def somefunction( deprecatedName('x) y: Int) = ...

 This gives deprecation warning to callers using the parameter name x.


 More info. In Scala annotations are user-defined, I presume, have methods,
etc.:

 http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/deprecatedName.html

 This helps against one of the problems Don has with named arguments.

I read 2-3 times Walter thinks warnings are bad. Things are either correct, or 
not. Right, I can understand; if the language is correctly designed, then there 
is no true "grey zone" (think C's numerous unsafe/border uses).
But language changes are not about correct/incorrect language use by 
programmers; instead, their use is initially correct. When the language itself 
evolves, precisely, warnings are a great tool to help evolving a code base 
synchronely (this is also attested by other languages).
Since D evolves fast, there could easily be hordes of warnings, which could 
turn very annoying. There should be a compilation setting (config file and/or 
command-line) turning off given warnings.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Jim <bitcirkel yahoo.com> writes:

spir Wrote:

 On 03/08/2011 09:29 AM, bearophile wrote:
 I don't know much about Scala language, so I've found this small funny thing
in the Lambda the Ultimate blog. In Scala parameter names can be deprecated:

 def somefunction( deprecatedName('x) y: Int) = ...

 This gives deprecation warning to callers using the parameter name x.


 More info. In Scala annotations are user-defined, I presume, have methods,
etc.:

 http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/deprecatedName.html

 This helps against one of the problems Don has with named arguments.

 
 I read 2-3 times Walter thinks warnings are bad. Things are either correct, or 
 not. Right, I can understand; if the language is correctly designed, then
there 
 is no true "grey zone" (think C's numerous unsafe/border uses).
 But language changes are not about correct/incorrect language use by 
 programmers; instead, their use is initially correct. When the language itself 
 evolves, precisely, warnings are a great tool to help evolving a code base 
 synchronely (this is also attested by other languages).
 Since D evolves fast, there could easily be hordes of warnings, which could 
 turn very annoying. There should be a compilation setting (config file and/or 
 command-line) turning off given warnings.


Yes, you could very well argue that the user's code is correct for the version
of the API it was written to use. A later, modified, version of the API does
not make the old programs incorrect so there should be no warnings OR ERRORS!

A correctly designed language supports means of defining and selecting versions
of interfaces and implementations. With this old and new code can interconnect
as long as they do not break the contract. For example, new versions of the
implementation should be just fine to use as long as the pre- and
post-conditions, invariants, and unit tests approve/pass. How do you solve that
in practice?

spir <denis.spir gmail.com> writes:

On 03/08/2011 02:43 PM, Jim wrote:
 spir Wrote:

 On 03/08/2011 09:29 AM, bearophile wrote:
 I don't know much about Scala language, so I've found this small funny thing
in the Lambda the Ultimate blog. In Scala parameter names can be deprecated:

 def somefunction( deprecatedName('x) y: Int) = ...

 This gives deprecation warning to callers using the parameter name x.


 More info. In Scala annotations are user-defined, I presume, have methods,
etc.:

 http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/deprecatedName.html

 This helps against one of the problems Don has with named arguments.

 I read 2-3 times Walter thinks warnings are bad. Things are either correct, or
 not. Right, I can understand; if the language is correctly designed, then there
 is no true "grey zone" (think C's numerous unsafe/border uses).
 But language changes are not about correct/incorrect language use by
 programmers; instead, their use is initially correct. When the language itself
 evolves, precisely, warnings are a great tool to help evolving a code base
 synchronely (this is also attested by other languages).
 Since D evolves fast, there could easily be hordes of warnings, which could
 turn very annoying. There should be a compilation setting (config file and/or
 command-line) turning off given warnings.


 Yes, you could very well argue that the user's code is correct for the version
of the API it was written to use. A later, modified, version of the API does
not make the old programs incorrect so there should be no warnings OR ERRORS!

 A correctly designed language supports means of defining and selecting
versions of interfaces and implementations. With this old and new code can
interconnect as long as they do not break the contract. For example, new
versions of the implementation should be just fine to use as long as the pre-
and post-conditions, invariants, and unit tests approve/pass. How do you solve
that in practice?

I did not mean anything like that at all, I guess. (Or do /I/ misunderstand 
you.) I meant warnings are a very practicle tool for devs to evolve their code 
base along with the language ('s reference version). Or, at the very minimum, 
know what in their code is sticked in the past!

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Jim <bitcirkel yahoo.com> writes:

spir Wrote:

 On 03/08/2011 02:43 PM, Jim wrote:
 spir Wrote:

 On 03/08/2011 09:29 AM, bearophile wrote:
 I don't know much about Scala language, so I've found this small funny thing
in the Lambda the Ultimate blog. In Scala parameter names can be deprecated:

 def somefunction( deprecatedName('x) y: Int) = ...

 This gives deprecation warning to callers using the parameter name x.


 More info. In Scala annotations are user-defined, I presume, have methods,
etc.:

 http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/deprecatedName.html

 This helps against one of the problems Don has with named arguments.

 I read 2-3 times Walter thinks warnings are bad. Things are either correct, or
 not. Right, I can understand; if the language is correctly designed, then there
 is no true "grey zone" (think C's numerous unsafe/border uses).
 But language changes are not about correct/incorrect language use by
 programmers; instead, their use is initially correct. When the language itself
 evolves, precisely, warnings are a great tool to help evolving a code base
 synchronely (this is also attested by other languages).
 Since D evolves fast, there could easily be hordes of warnings, which could
 turn very annoying. There should be a compilation setting (config file and/or
 command-line) turning off given warnings.


 Yes, you could very well argue that the user's code is correct for the version
of the API it was written to use. A later, modified, version of the API does
not make the old programs incorrect so there should be no warnings OR ERRORS!

 A correctly designed language supports means of defining and selecting
versions of interfaces and implementations. With this old and new code can
interconnect as long as they do not break the contract. For example, new
versions of the implementation should be just fine to use as long as the pre-
and post-conditions, invariants, and unit tests approve/pass. How do you solve
that in practice?

 
 I did not mean anything like that at all, I guess. (Or do /I/ misunderstand 
 you.) I meant warnings are a very practicle tool for devs to evolve their code 
 base along with the language ('s reference version). Or, at the very minimum, 
 know what in their code is sticked in the past!


I think that a program P written for version X of the compiler should not even
compile on version Y if any feature used in P have been changed between X and
Y. Program P should state which version it is developed for!

The same goes with APIs. This should really be a part of the language so that
errors do not sneak up on you because you update something. Warnings are not
good enough.

renoX <renozyx gmail.com> writes:

This 'deprecated' assertion is not about *language* changes but about
API changes.

I think that warning are a good compromise for changing API: can you
suggest something better?

BR,
renoX

bearophile <bearophileHUGS lycos.com> writes:

spir:

I read 2-3 times Walter thinks warnings are bad. Things are either correct, or
not.<

D compiler has the "-d" switch that allows deprecated features.

The old name becomes an alias of the true argument name when the "-d" is
used... but maybe a less blunt  switch is better.

auto somefunction( deprecatedName(x) int y) { ...

Bye,
bearophile

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, March 08, 2011 10:11:12 bearophile wrote:
 spir:
I read 2-3 times Walter thinks warnings are bad. Things are either
correct, or not.<

 
 D compiler has the "-d" switch that allows deprecated features.
 
 The old name becomes an alias of the true argument name when the "-d" is
 used... but maybe a less blunt  switch is better.
 
 auto somefunction( deprecatedName(x) int y) { ...

The workflow with regards to deprecating something in Phobos is to initially
mark 
it as "scheduled for deprecation" in the documentation. If a pragma can be 
targeted to the item in question, then a pragma is added as well to print out 
when that item is used in order to warn developers that the item in question is 
scheduled for deprecation (generally, that only works when deprecating an
entire 
module or when deprecating a template function - otherwise you usually get the 
pragma whether you used the soon-to-be deprecated item or not). It has been 
suggested that another level of deprecated be added for this (perhaps by giving 
deprecated an argument - e.g. deprecated(soft)), but that hasn't happened.

Regardless, after the item in question has been scheduled for deprecation for 
some period of time, it will be marked as deprecated. At that point, code which 
uses it will not compile unless you compile with -d. However, you _can_ still 
use it. After another period of time has passed, then the item will be removed 
entirely.

Essentially, we first warn programmers that the item in question is going to go 
away, but it doesn't affect their builds yet. Then we deprecate it, so if they 
haven't yet heeded the warnings that we gave them (albeit not warnings in the 
compiler sense of the term), then they'll have adjust their build to use -d. 
Finally, the item will be removed entirely, and if they haven't heeded the 
warnings by then, developers will just have to use an older version of Phobos
or 
copy the item in question to their own code.

I don't believe that the exact periods of time that something will be marked as 
scheduled for deprecation and how long it will it will be deprecated have been 
decided yet (it may depend on what's being deprecated), but the basic workflow 
has already been decided on and has been put into motion in a number of cases 
(e.g. std.date is currently scheduled for deprecation now that we have 
std.datetime).

So, if we introduced deprecated parameter names as Bearophile is suggesting, 
then they would presumably fit into the normal deprecation framework, acting
just 
like deprecated does.

- Jonathan M Davis