Question on Baobab's immutability

I really must be missing something, maybe someone can clue me in.

Here is what I mean:

var a = new Baobab({ b: 1 })
var c = a.set('b', 2)
a.get('b') // I expected 1 but got 2!
c // I expected a reference to the new tree but was surprised to see 2

Am I wrong to think that Baobab should work like ImmutableJS in terms of preserving the tree on mutations on just returning an updated version?

ImmutableJS doesn’t have by default the excellent cursors and event system on data change like Baobab does and that’s why I turned to using Baobab - but was a bit surprised that data mutated on every update.

[couchand]

Immutability is all in the eye of the beholder. The underlying data is stored on very mutable RAM, so we know that fundamentally everything is mutable, it’s about the API that’s exposed to the user.

Consider this snippet, the first from the ImmutableJS README:

var Immutable = require('immutable');
var map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = map1.set('b', 50);
map1.get('b'); // 2
map2.get('b'); // 50

Or this one, the second example from the mori README:

var v1 = mori.vector(1,2,3);
var v2 = mori.conj(v1, 4);
v1.toString(); // => '[1 2 3]'
v2.toString(); // => '[1 2 3 4]'

The fact that these examples are so primary to the explanation of these two libraries should be a sign that they’re following the expected pattern for immutable data structures. That Baobab would be described as immutable and persistent, despite that fact that the API plainly isn’t, seems like a case of buzzword-compliance.

Let’s not water down the meaning of the terms.

[dumconstantin]

👍 +1