Can we change the Intl prototypes to be normal objects?

[anba]

From https://bugzilla.mozilla.org/show_bug.cgi?id=1332604:

Intl.prototype.{Collator, DateTimeFormat, NumberFormat} are currently spec'ed as being instances of Intl.{Collator, DateTimeFormat, NumberFormat} (cf. 10.3, 11.4, 12.4). We should consider changing them to normal objects similar to how Date.prototype was changed to a normal object in the ECMAScript specification for ES6.

This change should be web-compatible because V8 already treats the prototype objects as normal objects.

[zbraniecki]

@caridy , @domenic , @littledan, @jungshik

[littledan]

Yep, let's do it!

[littledan]

cc other implementations @jswalden @thetalecrafter @bterlson

[vanwagonet]

Intl.NumberFormat.prototype.format(1234.5) currently throws in V8, but returns "1,234.5" in JSC. iirc, I interpreted the v2 spec to mean that the prototype object is a properly initialized Intl.* object.

Given that it currently throws in V8, I'd be really surprised if there is code in the wild that relies on JSC's current behavior. I think it would be good to have the prototypes be plain objects.

I'm willing to make the change in JSC once the spec change is approved.

[vanwagonet]

I did a quick pass at what the implications of this change might include:

Referencing Intl.Collator.prototype.compare, Intl.{DateTime,Number}Format.prototype.{format,formatToParts}, will throw an error. I think this makes sense, since they are defined as getters meant to be called on a properly initialized Intl object.

It's possible there is an expectation to be able to do Intl.Collator.prototype.compare.call(someCollator, a, b), but the spec has always been for getters of bound functions, so it wouldn't have used comeCollator's options anyway. This does make the change a little less analogous to Date.prototype, though.

Calling Intl.*.prototype.resolvedOptions() will throw an error. The only use case I could see, is to try to get the base defaults, which you can already do by creating an Intl.* object without passing any arguments.

[vanwagonet]

https://bugs.webkit.org/show_bug.cgi?id=168178

[rwaldron]

@ericf ping

[caridy]

@thetalecrafter it seems that your ticked was resolved.

I will like to bring this up in the next meeting, and try to get consensus to merge #148. I wonder what's @bterlson's position considering that Chakra is not throwing for Intl.NumberFormat.prototype.format(1234.5).

[vanwagonet]

@caridy Yeah the ticket was closed in April. The change is in the current technology preview and should be in Safari 11.

[rwaldron]

@caridy Is this no longer an issue in Intl.js?

[caridy]

@rwaldron it is not longer an issue there:

> Intl.NumberFormat.prototype.format(1234.5)
TypeError: `this` value for format() is not an initialized Intl.NumberFormat object.
    at NumberFormatConstructor.GetFormatNumber (/Users/cpatino/repo/Intl.js/lib/core.js:2431:70)
    at repl:1:28

[caridy]

I have confirmed that V8, SpiderMonkey, Intl.js and JSC (technology preview) are aligned with this. I have opened the issue for ChakraCore as instructed by @bterlson for the fix.

It seems that we are all in agreement.

[leobalter]

Do we need to bring this to the meeting or are we all set here? We have tests ready to land.

[littledan]

Sounds like it's ready for @caridy to land. The tests can be landed once the spec patch is landed.

[littledan]

I merged the PR based on the consensus that @caridy mentioned above, so tests should be good to land.