And spec'ing the union of every browser's quirks is not practical.
Chrome's implementation, in particular, is very lenient, even accepting
"JanZ ..Zu.aZ.r.Zzy.Z . 1 .... 2016" as 2016-01-01.
On 6/9/16 2:09 PM, Jim Blandy wrote:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
On Thu, Jun 9, 2016 at 11:42 AM, Jim Blandy
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
