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
Just an observation. Since #{a, b} is logically equivalent to #{b, a}, you'll need a test to make sure that they return the same stringification, and may indeed want to specify that stringifying a Record means the keys are in a particular order.
Maybe the same for toPrimitive, valueOf cases.
The text was updated successfully, but these errors were encountered:
Yes, there will be no way to observe the differences. I'd expect toString() to print out the keys sorted in the same sort order we use for Reflect.ownKeys. I think this will become more clear when we have the draft spec text written, and just fall out of the semantics.
Whether or not Record has non-null prototype that can hold a toString method is still up for debate in issue #71, but I think the answer to this question is the same regardless. Serialization/stringification of Records and Tuples will be deterministic for the same input value, and a record's properties are ordered, so the semantics of JSON.stringify mean that this will naturally happen, we won't need to do anything special here.
Just an observation. Since #{a, b} is logically equivalent to #{b, a}, you'll need a test to make sure that they return the same stringification, and may indeed want to specify that stringifying a Record means the keys are in a particular order.
Maybe the same for toPrimitive, valueOf cases.
The text was updated successfully, but these errors were encountered: