Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immutable.js – Immutable Data Collections

facebook.github.io

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Immutable.js – Immutable Data Collections

#41

Post by optymizer »

leebyron wrote: post #24
ScottBurson wrote: post #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, f…

This is great feedback and a decision that I didn't take lightly. I ultimately decided that the mental cost of remembering a new API would outweigh the potential for accidental return value mis-management. It's hard to make a decision like this sans-data, so I had to make a gut call. I'm really interested to hear feedback of issues encountered in-practice due to this. Of course, if I'm wrong about this (and there's a…

How about just adding aliases to existing methods, e.g. plus() and add()?

Re: Immutable.js – Immutable Data Collections

#42

Post by ScottBurson »

leebyron wrote: post #24
ScottBurson wrote: post #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, f…

This is great feedback and a decision that I didn't take lightly. I ultimately decided that the mental cost of remembering a new API would outweigh the potential for accidental return value mis-management. It's hard to make a decision like this sans-data, so I had to make a gut call. I'm really interested to hear feedback of issues encountered in-practice due to this. Of course, if I'm wrong about this (and there's a…

You've clearly put a massive amount of work into this API, which I applaud.

One trick I use in FSet that you might want to copy is default values for maps. This is particularly handy when the range type of the map is another collection: you can make the default value be the appropriate kind of empty collection, making it unnecessary for code that accesses the map to check for a null value. In Java, for example:

  FMap> m = new FHashMap.withDefault(FHashSet.emptyMap());
  // now I can do:
  for (Bar b : m.get(x)) ...
  // without worrying about whether 'm' contains an entry for 'x'.

Re: Immutable.js – Immutable Data Collections

#43

Post by pimlottc »

ninjakeyboard wrote: post #14
ScottBurson wrote: post #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, f…

Not sure if I agree - it's more natural to have only immutable collections if taking a functional approach. Eg see scala or haskell. Does strong typing change that? It's very clear if you're whole code base has no side effects what is happening when and where.

> It's very clear if you're whole code base has no side effects what is happening when and where.

And how likely is that? It's great if you start with a purely functional project but in most projects you're starting with a existing codebase, and you don't always have the time to go back and change everything when you figure out a better way to do it.

So I don't think it would be that unusual for someone to want to use immutable objects alongside alongside "normal" mutable objects. But it would be harder to distinguish the two in code when the methods are all the same, particular when you don't have type information at hand.

Re: Immutable.js – Immutable Data Collections

#44

Post by pimlottc »

leebyron wrote: post #24
ScottBurson wrote: post #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, f…

This is great feedback and a decision that I didn't take lightly. I ultimately decided that the mental cost of remembering a new API would outweigh the potential for accidental return value mis-management. It's hard to make a decision like this sans-data, so I had to make a gut call. I'm really interested to hear feedback of issues encountered in-practice due to this. Of course, if I'm wrong about this (and there's a…

But it's not the same API. There is a clear and plain specification on what each of those operations do, and the methods on these objects do not do them. I get what you're thinking about re-using what the programmer already knows but this only poisons the well by adding confusion to their existing knowledge. "Push adds a value to a list, oh wait, except it depends what type of list".

It is much easier to remember that "foo always does 'a'" and "bar always does 'b'" rather than "foo does 'a' for some things but does 'b' for others", it's why we create functions and objects with different behaviors instead of nesting lots of if statements.

New objects with new behaviors should use new language.

Re: Immutable.js – Immutable Data Collections

#45

Post by rpwverheij »

franciscop wrote: post #27

I think I'm getting the example wrong. Wouldn't this: var map = Immutable.Map({a:1, b:2, c:3}); map = map.set('b', 20); map.get('b'); // 20 Give 2 instead of 20, since b is inmutable?

to put what rtfeldman said in code:

    var map = Immutable.Map({a:1, b:2, c:3});
    var map2 = map.set('b', 20);
    map.get('b'); // 2
    map2.get('b'); // 20

Re: Immutable.js – Immutable Data Collections

#46

Post by rpwverheij »

"Subscribing to data events throughout your application [..] creates a huge overhead"

So could I do without event listeners when using Immutable data? Say I have a view listening to data changes with event listeners... could I notify it about changes in data without listeners if I use immutable data?

Re: Immutable.js – Immutable Data Collections

#47

Post by hibbelig »

jypie wrote: post #5

What 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…

Say you have this code:

    var x = {a: 1, b: 2};
    y = foo(x);
    // What is the value of x.b here?
With mutable data structures, `x.b` might have changed. If you make `x` an immutable data structure, then you can be sure that `x.b` has not changed.

This is a trivial example, but for larger programs it's going to be quite valuable to know that these kinds of changes have not happened. Maybe `foo` needs to "modify" the data structure in order to compute the final result.

With mutable data structures, what `foo` will do is to create a copy of the data structure `x`:

    function foo(x) {
        x = deep_copy(x);
        // The following assignment changes the copy,
        // no effect on the original parameter.
        x.b = 5;
    }
I just made up that "deep_copy" name -- I think you get what I mean. I don't know how it is written in JS.

I think you can see that "deep_copy" is going to be an expensive operation if `x` is a large data structure.

Re: Immutable.js – Immutable Data Collections

#48

Post by malandrew »

leebyron wrote: post #25
ebabchick wrote: post #8

Random 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

Not nefarious, but definitely something to keep in mind if you recruit via github committer lists :) I accept any reasonable pull request, even if it's a spelling fix. There have been some great bug fix pulls as well.

`git summary` from git-extras is great.

https://github.com/tj/git-extras

Re: Immutable.js – Immutable Data Collections

#50

Post by gcanti »

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment:

Pros:

- you can use native data structures instead of continually wrap / unwrap

- you can use native methods on them (map, filter, ...)

- hence (almost) no interoperability problems with other libraries

- overall your coding style doesn't change so much

- (possible perf gains since the js engine knows the object is frozen? - I really don't know)

- EDIT: 0KB dependency

Cons:

- you must find / write a way to update efficiently

Post reply on HN