通过利用javascript原型系统创建共享结构的不可变对象是否有意义

Question

So far, there seem to be two opposing solutions to immutability in Javascript:

• immutable.js
• seamless-immutable

immutable.js introduces their own (shallowly) immutable objects that are incompatible with the default javascript protocols for objects and arrays.

seamless-immutable uses POJOs that are completely immutable without any magic, but do without structural sharing.

It would be great to combine the best of both worlds. Could immutable prototype chains/trees be a proper solution?

The underlying prototype mechanism gives hope:

var a = [1, 2, 3];
var b = Object.create(a);

b[0]; // 1
b.map(function (x) { return ++x; }); // 2, 3, 4 

b.push(4, 5, 6); // initial assignment of b
a; // 1, 2, 3
b;  // 1, 2, 3, 4, 5, 6

for (var i = 0; i < b.length; i++) {
  console.log(b[i]);
} // 1, 2, 3, 4, 5, 6

a[1] = null; // prototype mutation
a; // 1, null, 3
b; // 1, null, 3, 4, 5, 6

b.unshift(0); // instance mutation
a; // 1, null, 3
b; // 0, 1, null, 3, 4, 5, 6 !!!

Whenever a mutation (unshift) of the current instance (b) makes it impossible for its prototypes to provide their values, the js engine seems to copy these values straight into the instance automatically. I didn't know that, but it makes total sense.

However, working with immutable (keyed/indexed) objects one quickly encounters problems:

var a = [1, 2, 3];
Object.freeze(a);
var b = Object.create(a);
b.push(4, 5, 6); // Error: Cannot assign to read only property "length"
Object.freeze(b);

This one is simple: The length property is inherited from the immutable prototype and hence not mutable. Fixing the problem isn't hard:

var b = Object.create(a, {length: {value: a.length, writable: true}});

But there will probably be other issues, in particular in more complex, real world scenarios.

Maybe someone have already dealt with this idea and can tell me, if it's worth reasoning about it.

Aadit's answer to a related question and Bergi's comment on it touches my question without giving an answer.

Answer 1

the js engine seems to copy these values straight into the instance automatically

That's because all the array methods ( shift , push etc) just use assignment to indices (and fortunately, to .length , which isn't automatically updated on non-arrays). As you know, assignment just creates a new property on the inheriting object, even if the prototype had that property (unless it has weird attributes, like in your frozen-length example).

Regardless, your actual question was

Could immutable prototype chains/trees be a proper solution?

No . The problem is that a prototype chain is never garbage-collected. The engine doesn't know that you "don't need" the prototype any more once all the inherited properties are overwritten by your new "mutated" instance - and keeps it around forever.
You'd need to manually garbage-collect (dereference) it, which is just what immutable.js with its structural sharing does. Only that mutating the [[prototype]] is a bad idea , so you better manage your structures in other ways and do property lookup manually.

Answer 2

In addition to memory leaking you encounter further problems when you use the prototype system for structural sharing:

• unfavorable lookup time in long prototype chains
• in ES5 loss of [[DefineOwnProperty]] in connection with arrays

Lookups in hash tables are usually very efficient. If an object is frequently mutated, however, very long prototype chains may arise. In the worst case the entire chain must be traversed. If such behavior occurs on a regular basis, it can have an adverse effect on performance.

Array subclassing leads to the loss of [[DefineOwnProperty]] . This internal method is responsible for synchronizing the length property with the actual number of elements in arrays:

function A() {}
A.prototype = Array.prototype;
var a = new A();

a[0] = 0, a[1] = 1;
console.log(a.length); // 0
a.length = 2;
console.log(a); // [0, 1]
a.length = 1;
console.log(a[1]); // 1

[opinion]I am convinced that all these problems can be solved and that with incredibly little code, a tiny API and a shallow learning curve. Such a system would likely not be as efficient as immutable data structures based on vector or hash map tries. But it would be much more efficient than mere copying of objects.[/opinion]