Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why use Object.create in exercise 19? #115

Closed
prashcr opened this issue Nov 27, 2015 · 7 comments · Fixed by #132
Closed

Why use Object.create in exercise 19? #115

prashcr opened this issue Nov 27, 2015 · 7 comments · Fixed by #132
Labels

Comments

@prashcr
Copy link

prashcr commented Nov 27, 2015

In the exercise, Object.create is used to "create a fast copy of the accumulated map".
I don't see what's fast or useful about using Object.create instead of simply mutating the map.
I ran tests, and I see no reason why Object.create should be used instead.

http://jsperf.com/object-create-vs-mutation-in-reduce/2

@ghost
Copy link

ghost commented Jan 12, 2016

I'm no expert, but I figured from reading it that they were addressing mutable vs. immutable data constructs. They even admit in the explanation paragraph (currently anyway) that it is slower than mutating the object:

// Object.create() is perfect for functional programming because it
// makes creating a new object with a different member value almost
// as cheap as changing the member on the original object!

Edit: You can see a slightly more real world example of Object.create in exercise 37:

function(queue, movieListsMessage) {
  var copyOfMovieLists = Object.create(movieListsMessage.list);
  if (queue !== undefined) {
    copyOfMovieLists.push(queue);
  }
  return copyOfMovieLists;
});

They call the variable copyOfMovieLists, so it looks like it's a nifty way to do an immutable copy of a list.

@kurzninja
Copy link
Contributor

As @bill-mybiz said, I'm not expert but I think he's right: mutating the original copy through out the call stack would be considered a "side effect" and not very "functional". Creating and returning a new copy would preserve state of the input of each call while still giving you the correctly mutated copy on return.

@prashcr
Copy link
Author

prashcr commented Jan 12, 2016

Hmm, I understand
90% speed penalty is definitely too much for real world use though.

I was curious as to how a typical immutable JS library would perform, check it out
http://jsperf.com/object-create-vs-mutation-in-reduce/4
50% penalty this time.

Would love to see even better perf

@gabrielkunkel
Copy link
Contributor

Aside from performance, it makes testing a pain, because Jasmine won't look at the prototype properties.

@varungupta85
Copy link

@gabrielkunkel In that case, would Object.assign be a better alternative and it turns out that Object.assign is faster than Object.create at least according to the below test which is edited from test from @prashcr
http://jsperf.com/object-create-vs-mutation-in-reduce/6

@morenoh149
Copy link
Collaborator

would both create and assign achieve the desired effect?

@gabrielkunkel
Copy link
Contributor

@varungupta85 Yes! Aside from being a little bit faster than Object.create(), Object.assign() is more testable with Jasmine. (Solves the issue I ran into while going through the tutorial.)

@morenoh149 They do different things, but for the sake of the tutorial they do achieve the same desired effect.

See my pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants