initializedIntlObject mechanics still necessary?

[littledan]

In ECMA 402 v1, the internal slot [[initializedIntlObject]] provided the function of ensuring that a single object didn't have the constructor called on it multiple times for different Intl constructors. However, with ECMA 402 v2 and greater, you can't initialize an existing object as in intl object. Are the mechanics still needed? cc @rwaldron

[zbraniecki]

@allenwb , @annevk @domenic ?

[allenwb]

shouldn't be needed, as long as all the constructor starts with a line like:

If NewTarget is undefined, throw a TypeError exception.

see, for example: https://tc39.github.io/ecma262/#sec-map-iterable

(corrected should to shouldn't)

[caridy]

Ok, I can take care of this as part of the clean up process before the next cut.

[vanwagonet]

fwiw JSC does not implement a concrete [[initializedIntlObject]] slot. I believe if we removed the v1 compat fallback, it wouldn't have an observable effect.

As a js dev, I would like to keep the v2+ mechanism of calling without new behaving the same as calling with new. ES2015 classes throwing without the new keyword leads me to stick with ES5 constructors where possible.

[littledan]

@thetalecrafter I was suggesting a purely editorial change, nothing to change observable semantics. It seems like [[initializedIntlObject]] doesn't really do anything anymore in v2+ as the path where it is false is dead code. That doesn't have anything to do with new-less constructors, which are implemented in the first line of constructors as "If NewTarget is undefined, let newTarget be the active function object, else let newTarget be NewTarget."

[vanwagonet]

@littledan sounds good. @allenwb's comment gave me the impression there would be a necessary change in behavior.

[littledan]

Oh, somehow I missed that.

@allenwb , two questions:

1. Intl constructors don't start with that line; instead they start with the following line. Does that change anything?

If NewTarget is undefined, let newTarget be the active function object, else let newTarget be NewTarget.

2. I don't see the Map object having such an internal slot. What are you saying is needed exactly?

[allenwb]

@littledan

1. No, that line is fine. It simply means that calling the constructor as a function is equivalent to using it in a new expression. Since that was the legacy 1.0 behavior, that's presumably want we want.

2. No internal slot is needed anymore to track initialization. That slot was only necessary when Intl constructors where separated into observably distinct allocation and initialization steps.

3. (probably off topic) the purpose of the "Normative Optional" steps isn't obvious from the text. Why might or might not an implementation choose to include them? Regardless, of the purpose, step 4 seems buggy. If DateTimeFormat is invoked using [[Construct]] (i.e., if NewTarget is undefined) then "the this value" will be uninitialized and it is meaningless to access its value.

[littledan]

3. I don't think the Construct case is relevant here, see the bug at [Compatibility Hazard] ECMA 402 2nd Edition Changed the [[Call]] Behavior of Intl Constructors #57 which motivated this case.

That's a good idea to give more context. I'll add a note.

I can't speak to the case for not implementing it, as I work on an implementation which does implement Annex B. Maybe @erights can give more context here, which we could work into the note.

[erights]

@littledan sure:
#57 (comment)
https://bugs.webkit.org/show_bug.cgi?id=153679#c3

But is this entire kludge still necessary? When the issue was first raised, I thought it was described as a transitional issue that would soon be behind us. If we did not do any of this kludge, what would still break?

[littledan]

@erights I meant more about the motivation for why it should be normative-optional rather than simply normative; I couldn't find that detail in the links you provided.

To research whether this compat fix is still necessary, maybe someone could put statistics collections in browsers. The simpler path would be to just try shipping pure v2 semantics again, but I'm hesitant to do that since we know that broke websites the last time, and we've worked out a fix which already made it to multiple implementations and the draft spec.

[erights]

Well, the two are tied together. The reason it is normative-optional is so that implementations are free to stop shipping the kludge as soon as they judge that they no longer need to.

[caridy]

@littledan send the PR about If NewTarget is undefined, throw a TypeError exception..

[erights]

I notice this issue is closed. What is the answer to the question? Is any of this kludge still needed? Do we know?

[vanwagonet]

I would love to kill the kludge if we don't need it anymore.

[littledan]

I'm not sure which kludge you're talking about. This bug was all about a purely editorial change, and it was possible to remove that kludge, see the above patch. I don't have any data about whether the kludge in initializing non-Intl objects as DateTimeFormat or NumberFormat is still needed; I'm not so confident, personally.