> In an immutable world, the coupling of functionality and data is extremely difficult to use because any functionality would have to be rebuilt any time the facts change.
This is wrong. The problem is lack of support for immutable data in Javascript, not with immutable data in itself. Consider the OCaml equivalent:
class person name = object
val _name = name
method name = name
method greet other =
"Hello " ^ (other # name) ^ ", my name is " ^ _name
method set_name name =
{< _name = name >}
end
This creates an immutable person class. Calling 'set_name' on a person creates a new person and the methods of that person use the new value. You can even use inheritance :
class whistleblower secrets name = object
inherit person name
val _secrets = secrets
end
let bradley = new whistleblower (...) "Bradley"
let chelsea = bradley # set_name "Chelsea"
The new person is an instance of "whistleblower" and has the same value for "_secrets" as the original object.
I found the initial example of a problem with context and this to be incredibly contrived. If you have people who hate you dropping bind into your code and misusing a function only meant to be used with constructor calls, why wouldn't they do the same thing with your protocols?
By this author's logic, his own implementation is no good, because what if someone comes along and writes Protocol = "foo" in global scope? There's a difference between writing defensive code to prevent mistakes anyone could easily make, and trying to push your pet implementation forward through ridiculous hypotheticals.
Also, no mention of ES6 fat arrow functions and no mention of Immutable.js indicate that maybe this guy isn't interested in solving problems as much as he is in promoting his personal style.
Yeah, an example which doesn't involve "assume the caller will deliberately use your API wrong" would have helped me maintain my suspension of disbelief.
Yet another article written by someone who doesn't have enough perspective to understand when the failure is a failure of Javascript rather than a failure of a fundamental concept.
It's great that JavaScript is flexible enough to allow these completely different styles without requiring any changes to the language, but I wonder if the author wouldn't be better served by switching to a language that uses similar patterns but with better syntax.
Introspecting into this code seems very complicated and could make future refactors painful.
It seems like we're using dynamic language features and metaprogramming facilities to try and jury-rig something that would solve exactly the problem that static type systems are designed to solve. I'd rather trust people to call new Dog() instead of Dog.bind(cat), or alternatively I might just use TypeScript and my code will still look mostly like JavaScript.
Btw react-with-addons ships with react.addons.update which gives effcent enough immutable updates without needing to leave plain old is data structures like the mentioned mori and immutablejs. I don't know why react.addons.update was released with such cripplingly bad syntax, but you can trivially use it to implement clojure's assoc, update-in and the like, see here: https://github.com/dustingetz/update-in (this tiny library is production quality and the basis of react-cursor). When my consulting clients are ready to taste immutability but have all this jquery style code that they can't leave behind and which isn't compatible with redux, I point them in this direction. (Hi from RC batch S'12!)
> When we change the name of our functional object by copying it and refreezing, we will not change the functions inside the object. All those functions will still only have access to the old version of the object through reference.
That is why I use deep-freeze. I also have a mutate/copy function that only changes from the changed property up to the root. Everything that can stay frozen as the original object will stay frozen.
This is wrong. The problem is lack of support for immutable data in Javascript, not with immutable data in itself. Consider the OCaml equivalent:
This creates an immutable person class. Calling 'set_name' on a person creates a new person and the methods of that person use the new value. You can even use inheritance : The new person is an instance of "whistleblower" and has the same value for "_secrets" as the original object.