Immutable.js – Immutable Data Collections
facebook.github.io
Immutable.js – Immutable Data Collections
1–10 of 86 posts
Re: Immutable.js – Immutable Data Collections
#2Nice!!!
Re: Immutable.js – Immutable Data Collections
#3Was this really hosted on Facebook initially? I remember this library before May, which is the date of the initial commit.
Re: Immutable.js – Immutable Data Collections
#4> The difference for the immutable collections is that methods which would mutate the collection, like 'push', 'set', 'unshift' or 'splice' instead return a new immutable collection.
I think this is an unfortunate design decision which should be reconsidered. Functional operations should have different names than side-effecting operations. In general, I think that while side-effecting operations are commonly verbs, functional operations should be nouns or prepositions.
Particularly in a language without static types, you want to be able to look at an unfamiliar piece of code and see pretty quickly what types it is using. The semantics of mutable and functional collections are similar enough that using the same names is going to be very confusing, particularly in code that uses both kinds of collection -- and such code will definitely exist.
It's important that the names convey the semantics of the operation. Java's 'BigInteger' is a good example of this being done wrong -- the addition operation is called 'add', for example, and I have read that some newbies call it without assigning the return value to something, expecting it to be a side-effecting operation. I think that if it were called 'plus', such an error would be much less likely. We're used to thinking of "a + b" as an expression that returns a value, rather than an object with state.
I understand that introducing new names has a cost: people have to learn them. But keeping the old names is going to drive users nuts. If you won't change the names altogether, at least append an "F" to them or something.
EDITED to add: if you want some ideas, check out FSet: http://www.ergy.com/FSet.html
Re: Immutable.js – Immutable Data Collections
#5What is the benefit of having immutable variables that are just fake-built at runtime? At compile time, knowing some variables are constant and will not change would give the interpreter/compiler a lot of optimization chances but does this apply the same at runtime as well?
the website says "efficiency" because immutable variables wouldn't need to be deep copied but would the deep copy operations be that frequent in JS?
Re: Immutable.js – Immutable Data Collections
#6What is the benefit of having immutable variables that are just fake-built at runtime? At compile time, knowing some variables are constant and will not change would give the interpreter/compiler a lot of optimization chances but does this apply the same at runtime as well? the website says "efficiency" because immutable variables wouldn't need to be deep copied but would the deep copy operations be that frequent in…
One benefit is that you can do simple O(1) equality comparisons in UI libraries like React to determine whether data has changed (and thus whether UI needs to be refreshed).
Re: Immutable.js – Immutable Data Collections
#7Was this really hosted on Facebook initially? I remember this library before May, which is the date of the initial commit.
This was always Facebook's library, but it didn't always have a pretty homepage. You might be thinking of mori? https://github.com/swannodette/mori
Re: Immutable.js – Immutable Data Collections
#8Random observation -- what's up with almost 20 of the 24 'contributors' to this project mostly having made 1 edit changes to the README? Is this some kind of pervasive Github resume padding scheme that I'm just now picking up on? (it will show the repo in the "Repositories contributed to" section of your profile even for just those 1-line README edits)
https://github.com/facebook/immutable-js/graphs/contributors
Re: Immutable.js – Immutable Data Collections
#9Random observation -- what's up with almost 20 of the 24 'contributors' to this project mostly having made 1 edit changes to the README? Is this some kind of pervasive Github resume padding scheme that I'm just now picking up on? (it will show the repo in the "Repositories contributed to" section of your profile even for just those 1-line README edits) https://github.com/facebook/immutable-js/graphs/contributors
It's possible, but it's also standard practice on github to submit even minor typos or spelling errors via a pull request, and that automatically makes you a contributor if accepted. So there's not necessarily anything nefarious going on.
Re: Immutable.js – Immutable Data Collections
#10Random observation -- what's up with almost 20 of the 24 'contributors' to this project mostly having made 1 edit changes to the README? Is this some kind of pervasive Github resume padding scheme that I'm just now picking up on? (it will show the repo in the "Repositories contributed to" section of your profile even for just those 1-line README edits) https://github.com/facebook/immutable-js/graphs/contributors
As the supposed #2 contributor to the project (with 3 commits), I'd say it's far more likely that the README is simply the most visible piece of the project (or was, before the website was released today) and people contribute back typo fixes as they encounter errors.