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.
