You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The resolveOptions still return an object which prototype is %ObjectPrototype%.
I think it's valuable to check this is still effective, so one can benefit of this inheritance for the returned value (using toString, etc).
One other good thing for this test is: GetOption should not trigger any observable behaving on the Object.prototype for this new created options. You can verify it this using a Object.defineProperty(Object.prototype, "type", { get() { throw new Test262Error() } } );. This way you also assert the proper GetOption(options, type, ... operation.
We should test this on all Intl resolvedOptions return values.
I bet there are lots of object model sort of interactions that lack detailed test coverage. Until recently, there wasn't even a test of whether the prototypes of Intl objects were instances of their class, for example. This is worthy of a thorough look through the spec and tests.
The text was updated successfully, but these errors were encountered:
From #1350, @leobalter wrote,
We should test this on all Intl resolvedOptions return values.
I bet there are lots of object model sort of interactions that lack detailed test coverage. Until recently, there wasn't even a test of whether the prototypes of Intl objects were instances of their class, for example. This is worthy of a thorough look through the spec and tests.
The text was updated successfully, but these errors were encountered: