3 ms·
as outlined in the proposal, these new types have engine level guarantees, and support using a plain triple equals (`===`) statement to test structural equality
by no_wizard 4y ago
as outlined in the proposal, these new types have engine level guarantees, and support using a plain triple equals (`===`) statement to test structural equality. It also follows that strucural equality trickles down into objects that do this implicitly (Map, Set etc) as well.
Doing this for plain arrays and objects has been said by the vendors for years to be too hard and possibly break alot of existing applications, and a new type for this purpose would need to be proposed. This is an answer to that. There isn't much to be semantically gained by allowing this on frozen objects, you'd need to do something identical to this anyway, from an engine perspective. Using a new syntax / types to represent it semantically makes it easier for developers to understand it too, I'd argue.
- scotty79 4y agoYou could create class that keeps static Map with references to all created objects of given type. On creation it would check if structurally same object was already created and return reference to previous instance instead of creating a new one. If you freeze those objects and their prototypes you get exactly your records. === becomes structural comparison that costs exactly the same as reference comparison. I made something like that for my own purposes for very simple types like Point. To implement this you'd just need to be able to turn contents of an object into a key for a map. I agree that it's probably better to do this rather in the VM than in the library.
- sfink 4y agoI believe this approach was proposed, but implementers pushed back because the initial interning is expensive and there are a lot of scenarios where it would never be used. You don't really expect creating a Point to do a hash lookup.
- deleted 4y ago[deleted]