ecmascript-immutable-data-structures
ecmascript-immutable-data-structures copied to clipboard
Need to use .set and .get
I don't see anywhere in docs but I'd like to treat my immutable data structures like normal JS ones, in that I dislike having to use get
and set
rather than just =
. I assumed this spec would have something along those lines but I didn't see it explicitly.
The problem is that a normal =
can't work for most cases.
(I don't see any mention of .get
and .set
in the documents for vectors. (Which is probably an oversight))
For example, take the example of a vector.
var a = #[1, 2, 3, 4]
Now, of course, it should be possible to easily read values:
a[0] === 1
But you can't use assignment to update the vector:
a[0] = 9 // Doesn't work
This is because, by definition, these data structures are immutable.
a = a.set(0, 9) // sadly there is no mentions of a .set in the docs so far.
This is actually the same way that strings work in Javascript:
var str = 'abc'
str = str + 'def'
str[1] === 'b'
str[1] = 'c' // doesn't work
The only way to assignment work reliably would be to create a new value on every assignment. This can technically work, but seems to be complicated and confusing for Javascript.
Actually I apologize I wrote this late before I forgot about it but I don't think set is as important, just being able to get without explicit .get
would be nice.
@natew I agree with the subscript based get. But It would only work for vectors and records, as Maps take non-string, non-number strings as well.
As much as I'd like to be able to do avoid using .get
and .set
, I think that it's quite important to be able to polyfill this feature. Even though you could transform vector[0]
to vector.get(0)
the impossible part is to know when a variable is an immutable vector and not an array, which means that it cannot be polyfilled.
Index and property access without get/set can always be added at a later stage.
I agree that .get
is something that would need to be kept around. That said subscripts would be a huge benefit as well.