From:  Jim Blandy <jblandy@mozilla.com>
Date:  10 Jun 2016 05:09:22 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Improving Date.parse

NNTP-Posting-Host:  63.245.214.181

The more I think about this, the more I'm coming around to Shaver's
position. The volume of code on the web is such that it's not a bad first
approximation to just think of it as a complete cover of every observable
behavior the APIs exhibit. And so much of it is poorly maintained, or not
actively maintained at all. So changing anything at all is just guaranteed
to break things that will never get fixed.

Adding a new method doesn't make people notice it or use it. People will
still crib from old code that calls the Date constructor. But that's the
status quo; you haven't made anything worse than it is already. And for
actively maintained code, web developers are used to tracking progressing
standards, and knowing what the modern thing to use is; a new Date method
will participate in that process like everything else. Consider how well
moment.js has been picked up, even as a third-party library.

Following the "complete cover" principle, adding a new method to Date is
going to break something too: there's guaranteed to be crazy code that
somehow depends on the new function not being there. But that's going to be
a much smaller impact than changing the behavior of something ancient and
widely used, like the Date constructor.



On Thu, Jun 9, 2016 at 1:25 PM, Jim Blandy  wrote:

> I certainly get the argument in favor of new APIs over changes to old APIs.
>
> But when an API behaves inconsistently from one browser to the next, it
> seems to me the argument for preserving its specification gets a lot
> weaker. ECMAScript has pinned down under-specified behaviors plenty of
> times.
>
>
> On Thu, Jun 9, 2016 at 11:54 AM, Mike Shaver 
> wrote:
>
>> I agree with the motivation of the proposal: provide reliable
>> cross-browser date parsing capability. The choices are:
>>
>> - change the behaviour of an existing, fragile API
>> - add a new API with well-specified behaviour
>>
>> To take advantage of the former case, a program must know that it's
>> running in an engine that has updated to the spec, by version checks or
>> (less likely on the web, IMO) probing with known patterns. To be damaged by
>> the former case, it need only trip over an edge case that was deemed
>> insignificant.
>>
>> To take advantage of the latter case, a program must also know that it's
>> running in an engine that has update to the spec, but it can do that
>> through feature testing. A program can't be damaged by the latter case.
>>
>> I am in favour of the latter case.
>>
>> Mike
>>
>>
>> On Thu, Jun 9, 2016 at 11:49 AM, Jim Blandy  wrote:
>>
>>> I'm not sure where you're going with this, other than, yes, any
>>> observable change to an API can have a negative impact. Making behavior
>>> consistent across browsers often has a positive impact as well.
>>>
>>> Do the observations you made suggest ways to improve the proposal?
>>>
>>> On Thu, Jun 9, 2016 at 11:43 AM, Mike Shaver 
>>> wrote:
>>>
>>>> On Thu, Jun 9, 2016 at 11:42 AM, Jim Blandy 
>>>> wrote:
>>>>
>>>>> The current behavior varies from one browser to another anyway.
>>>>> Assuming the new grammar only codifies existing practice, won't any such
>>>>> programs already be behaving inconsistently across browsers?
>>>>>
>>>>
>>>> Many programs adapt to the browser they're running in.
>>>>
>>>> Mike
>>>>
>>>>
>>>
>>
>