SameValueZero comparator and compatibility
The most reliable way to get the implementations to conform is to contribute a test262 test.
As for how to contribute a test262 test, I am still confused about the situation and leave it for others to comment.
On Jan 21, 2014, at 9:58 AM, Brandon Benvie wrote:
The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality.
This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders.
This was pretty throughly discussed during TC39. SameValue0 is a very intentional choice. The marching orders are the spec.
I wish there was an answer to that too ... if implementors are confused, how could developers even think about contributing there?
I have expressed already my wishes for a "Test Driven Development" of JS specs/features but I find myself unable to help.
Any hint would be appreciated.
On Jan 21, 2014, at 2:09 PM, Andrea Giammarchi wrote:
I wish there was an answer to that too ... if implementors are confused, how could developers even think about contributing there?
I have expressed already my wishes for a "Test Driven Development" of JS specs/features but I find myself unable to help.
Any hint would be appreciated. Thanks
Assuming that there is already spec. material (which is now the cases for almost all of ES6) one way would be proceeded approximately as follows:
- Read the parts of the spec. you are going to implement.
- If there aren't yet any test262 tests for that material, write some. Writing such tests will probably help in your understanding of the spec. material
- Ask the feature champions and other interesting TC39 participants to review the tests in relationship to the spec.
- Use the tests to drive your initial implementation of the feature. Add more test262 level tests as to proceed.
- Contribute the tests, get other implementations to also test against them.
last 3 points are way too much high-level ... "ask feature champions" & "other TC39 participants" ... how? Just "trashing code" in test262-discuss?
On "my initial implementation" ... well, I can write the test accordingly with specs, it would be implementors eventually making the test green via their implementation/feature, not the other way round, right?
Getting other implementations to test against the test ... I believe this should be the automatic before any release procedure anyone that is supposed to follow specs should do, right? How can I be sure about that?
Wouldn't be wiser/simpler to put test262 files under Github instead of passing through a mailing list very hard to link against and point implementations?
Andrea Giammarchi wrote:
last 3 points are way too much high-level ... "ask feature champions" & "other TC39 participants" ... how? Just "trashing code" in test262-discuss?
Updating test262 is a good idea, but it's not the direct way to get these implementation bugs fixed. File bugs on SpiderMonkey and V8. Not sure how to give feedback on Chakra, but Brian (cc'ed) can help there.
Andrea Giammarchi wrote:
Wouldn't be wiser/simpler to put test262 files under Github instead of passing through a mailing list very hard to link against and point implementations?
The current plan of record as of the July meeting in Redmond is indeed to move Test262 to Github. Since then I have not had time to devote to the project, however Brandon Benvie has graciously volunteered to look into this and so I'm hopeful you will see something soon(tm).
There are some additional details here (such as a contributors' agreement, licensing of contributed test cases, and record-keeping requirements) that are being worked out with ECMA presently. I have put off documenting and evangelizing a decent process until this is complete. I believe once Test262 is on Github, coverage gaps and other bugs can be tracked with Issues and contributions submitted via Pull Request (and committed by ECMA members after review).
Brendan Eich wrote:
Not sure how to give feedback on Chakra, but Brian (cc'ed) can help there.
If it's a Chakra issue I definitely appreciate an email! The official feedback channel for all of IE is Connect, although it's mostly just a slower way to email me.
On Wed, Jan 22, 2014 at 3:53 PM, Brendan Eich <brendan at mozilla.com> wrote:
Updating test262 is a good idea, but it's not the direct way to get these implementation bugs fixed. File bugs on SpiderMonkey and V8. Not sure how to give feedback on Chakra, but Brian (cc'ed) can help there.
There was a SpiderMonkey bug, and even a patch, for this for quite a while. The patch now landed and will be in Firefox 29.
V8 got fixed last week too
but according to spec, "forEach" should call callback with "-0":
var map = new Map();
map.set(-0, 'x');
map.forEach(function (value, key) {
alert(1 / key);
});
alert(map.get(0));
V8 has no forEach.
On Feb 3, 2014, at 8:51 PM, Vic99999 wrote:
but according to spec, "forEach" should call callback with "-0":
Good catch! This allow applies to 'keys' and 'entries' enumeration.
I seems to me, that if we want -0 and 0 to act as the same key value, that we need to normalize -0 to 0 when storing it as a map key. SameValue0 remains what we want to use when doing a key lookup,
This is now bug ecmascript#2501
I have updated the working draft to normalize -0 keys to +0 in Map.prototype.set and Set.prototype.add
On Tue, Feb 4, 2014 at 3:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
This is now bug ecmascript#2501
I have updated the working draft to normalize -0 keys to +0 in Map.prototype.set and Set.prototype.add
The SpiderMonkey implementation does exactly this already.
The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality.
This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders.