Is there any interest in allowing mutable methods to return copies?

I’ve moved some bits around in a local clone of the repo so that rather than throwing an exception when any of the banned mutable methods are called, a quick copy is created and is mutated then returned as immutable.

Most of this logic happens in a new function.

function proxyMutableMethod(obj, methodName) {                                                                                                   
   var methodRef = obj[methodName];                                                                                                               

  addPropertyTo(obj, methodName, function() {                                                                                                    
    var host = obj instanceof Array ? [] : {},                                                                                                   
         copy = quickCopy(obj, host);

    methodRef.apply(copy, arguments);
    return Immutable(copy);
  });
}

Rather than calling banProperty for each of the banned methods, proxyMutableMethod is called instead.

Now aside from the obvious performance implications (all these operations become at least O(n)*) is there a reason why this isn’t already a feature of the library? I understand that the performance itself may be enough of a reason, but it makes it more friendly for people coming from Clojure or Immutable.js. Just want to know whether I’m missing something before I crack on with writing the tests and amending the docs so I can send a pull request.

* It wouldn’t be too much work to add an interface for defining structural sharing overrides for some of the mutable methods though.

[sudhakar]

👍 Started with seamless-immutable & after failing to easily splice, tried porting it to immutable-js. Now my app has become even more complex with all that get, setIn etc, I am now back here.

How about ruby sort of suffix for immutable methods like splice$ or splice_ ?

[rtfeldman]

@wesleytodd Instead of doing a = Immutable(a.asMutable().push(val)), I would do a variant of what @jokeyrhyme suggested:

a = Immutable(a).concat([4])

The main reason I went with the “explode when you try to mutate” design was to avoid pernicious bugs when changing over previously mutable code to use Immutable. This way if you ever forget to change something over from the old style to the new style, you’ll at least get an error!

As far as adding a separate set of methods to add this functionality, I like keeping the API intentionally simple, and I don’t think something like Immutable(a).afterPush(4) is enough added convenience over Immutable(a).concat([4]) to justify adding it.

Thanks for the spirited discussion! You folks are excellent. 😺