Difference with Object.freeze #4

Activity

1. jmorrell commented on Mar 11, 2015

   

   jmorrell

   on Mar 11, 2015

   More actions

   A couple of things from my understanding (might be wrong), mostly assuming the implementation in JS engines would be something like Immutablejs. There are probably more reasons that I'm unaware of.

   1. Value equality vs reference equality

   const x = Object.freeze([ 1, 2 ]);
   const y = Object.freeze([ 1, 2 ]);
   console.log(x === y); // false
   

   vs

   const x = #[ 1, 2 ];
   const y = #[ 1, 2 ];
   console.log(x === y); // true
   

   1. You can get additional memory optimizations in the implementation through structural sharing. In the first example above you have two arrays allocated. In the second example they are literally the same object. Lee Byron does a good job of explaining this in his ReactjsConf talk (start at 5 minutes)
   2. There is a cost to freezing objects. In the product I work on we recursively freeze all of the data while in dev mode, and it results in a considerable drop in performance vs prod where we don't freeze the objects.
   3. There is some wonkiness when working with frozen objects with regards to strict mode. In strict mode trying to modify a frozen object throws an error, while outside of strict mode it will fail silently.

   👍React with 👍1Reacted by Haroen Viaene
2. bcherny commented on May 6, 2015

   

   bcherny

   on May 6, 2015

   More actions

   @jmorrell this would be a significant departure from the way javascript preforms equality checks. The behavior should be the same for mutable and immutable reference types. ie.

   let a = [1, 2]
   let b = [1, 2]
   a == a // true
   b == b // true
   a == b // false
   
   let c = #[1, 2]
   let d = #[1, 2]
   c == c // true
   d == d // true
   c == d // false

   the only way to have the behavior you want is to use singletons under the hood. ie. when declaring d above, d would have a pointer to the same location in memory as c, so c == d would be true. this is similar to the way scala treats reference types, so that they behave like value types.