Combine Record and ImmutableMap

[nmn]

The combined type would work the same way as OrderedMap in Immutable-js

Since Records are about Data, it doesn't make sense to keep them limited to strings for keys.

Would like to know if there is a performance story to be made about Records.

[jeanlauliac]

Well what's interesting with Records is the ability to grab fields as usual foo.someField instead of foo.get('someField') with Maps. There's also a semantic difference, fields would generally stay the same on records, meaning it can be optimized by having plain objects (internally 'classes') instead of a full map data structure if the number of fields is small (< 32 for example, that is I believe the size of the internal tree nodes in Immutable.Map). Same difference between objects and Map in ES6, in a sense.

However, just as object, records should definitely accept Symbols as keys.

[nmn]

Symbols, are something that should definitely be added to the proposal. About merging Records and Immutable Maps, I still think it's worth exploring, unless there is a strong to be made about performance.

It is true that you don't need to use .get to get values from records. But I expect that property to ported over to combined data structure as well. I don't know why maps need .get either. You should be able to use map[key] to get values from maps. And the same should hold true for records.

Using the dot operator is something I'm not too keen on having. Immutable data structures are about data. Records aren't going to replace objects in code, but they provide a better way to store data.

[ckknight]

I think there is a clear separation between Records and ImmutableMaps.

Even though Records could be written in terms of ImmutableMaps, by keeping the API as small as possible for it, there is essentially no distinction between it a frozen object. Values are accessed through normal property access and it otherwise works as an ordinary object as long as you don't attempt to mutate it. Also, each "type" of Record would have its own distinct API. #{ x: 1 } and #{ y: 2 } need two different pieces of code to operate on them (unless one relies on more dynamic typing).

ImmutableMaps, on the other hand, have arbitrary-typed keys (not necessarily strings), and a generic API with extra capabilities (such as deleting an entry), not specific to any particular instantiation of an ImmutableMap. Two ImmutableMaps from completely separate parts of the code have the same, obvious API.

They solve different problems.