Deprecated argument names

[spir]

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