On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas <michalwa...@gmail.com> wrote:
> Simple idea: > > - Add new Annex to language. > - Define operation EmitDeprecationWarning(code) - implementations MAY > show deprecation warning in implementation dependent way (it can depend on > runtime flag, dev tools, not minified code, etc.); otherwise operation > EmitDeprecationWarning is noop > > Who sees the warnings? Publishers hire contractors to build (re-build) site in year N, in year N+M when contractors are long gone, users visit site and get unseen warnings in their unopened devtools. What upper bound can be put on M? > > - Define when implementations SHOULD emit deprecations warnings - like > using with statement, non-standard Reg-Exp properties, compile method, > assign to arguments, getYear etc. > > Who sees the warnings? Not the contractors, they are long gone by year N+1. > > - Language features can be removed after 10 (15?) years > > So M=10 might work (who knows?) but it's so long a time frame that no one will act on the remote threat of breakage. And yet at Y=N+M, there will be sites (not just web.archive.org) using the old feature, I would bet real money. We know this because from looking back at when the Web was smaller and easier to coordinate. Your model seems to assume a small-world-network coordination system. That's not the Web. I created JS in 1995. In 1996 I made a few incompatible changes to JS and got away with it, but not in 1997. ES3 was done in 1999 based on de-facto work in Netscape and IE that converged (mostly; a few edge cases) around the same time, but even by 1998 the only way to coordinate was via the ECMA-262 standards work, not just ES1 but the discussions about future work we were having in 1997. This kind of TC39 coordination helps for sure, don't get me wrong. But it does not solve the publisher/contractor division of labor leaving M effectively unbounded. For a language like Java or C# used server side, where the retrograde sites can stick to old tool/runtime versions as long as vendors support them, M can be a "Goldilocks" interval, not too big, not too small. The threat of vendors obsoleting old versions pushes most customers to upgrade in time, and the customers of size can push back and keep support going an extra year or three if need be. But that's not the Web. On the web, you don't just have the publishers and contractors, you have browser users also not coordinated except possibly by loose rules about supported browsers (banks try this and still get it wrong). Most sites do not want to turn away users based on detailed user agent version checks. Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share? I hope this helps. It's very hard to remove things on the Web. That's the nature of the beast. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
