Proxies have problem that you are unable to distinguish __proto__ properties and proxied properties. Imagine situation of storing key `filter` into `Immutable.Map`. How would you distinguish it from function `filter` defined on `Immutable.Map.prototype`?
Samuel > On 6.8.2015, at 20:35, Isiah Meadows <[email protected]> wrote: > > > The alternative is proxies. > > On Wed, Aug 5, 2015, 15:26 Samuel Hapák <[email protected] > <mailto:[email protected]>> wrote: > > Thank you for your reply Andreas! > > So, let's split this discussion into two parts: > > i) Whether there is a good use case for non-standard data structures like > Immutable.js in place of standard Objects. > > ii) If so, how to proceed with simplifying destructuring for these data > structures. > > Let's discuss the i) first. > > On 4.8.2015, at 14:26, Andreas Rossberg <[email protected] > <mailto:[email protected]>> wrote: > > As for a more Scala-like variant with distinguished syntax, I'm fine with > that semantically. But I still don't buy the specific motivation with maps. > Can you give a practical example where you'd want to create a map (immutable > or not) for something that is just a record of statically known shape? And > explain _why_ you need to do that? Surely it can't be immutability, since > objects can be frozen, too. > > Some people from FRP community believe that using non-mutable values is > superior over using mutating values. There are lot of resources online why > functional people prefer non-mutable values, one of them is famous Rich > Hickeys' talk: http://www.infoq.com/presentations/Value-Values > <http://www.infoq.com/presentations/Value-Values> > But we've got `Object.freeze()`, right? It should be remedy to all our > problems, right? Well, nope. > > The reason, why people use libraries like: > > https://github.com/facebook/immutable-js/ > <https://github.com/facebook/immutable-js/> (7760 stars) > > or > > https://github.com/swannodette/mori <https://github.com/swannodette/mori> > (1692 stars) > > is not object freezing. Actually, they don't freeze objects at all! They are > about how to manipulate immutable data easily and **efficiently**. > > Following code in traditional mutable programs: > > ```javascript > > let book = {title: "Harry Potter", author: {name: {first: "Joanne", last: > "Rowling"}, age: 49}} > > // It was J. K. Rowling's birthday at July 31st, let's increase the age > > book.author.age++ > > ``` > > Is hard to do when you deeply freeze the structure. But you can introduce > some helpers for the task: > > ```javascript > > let book = deeplyFreeze({title: "Harry Potter", author: {name: {first: > "Joanne", last: "Rowling"}, age: 49}}) > > // We use some convenience updateIn helper that clones the frozen structure > and creates new updated: > > book = updateIn(book, ['author', 'age'], (age) => age + 1) > > // results in > > // deeplyFreeze({title: "Harry Potter", author: {name: {first: "Joanne", > last: "Rowling"}, age: 50}}) > > ``` > > That was nice, but slooooooow:( Cloning objects on each tiny change. That's > hardly efficient. > > Fortunatelly, Phil Bagwell and Rich Hickey came up with cool concept of > structural sharing that can make immutable (also known as persistent) data > structures very efficient. It gives practically O(1) for both updates and > lookups. This is nice introductory post: > > http://hypirion.com/musings/understanding-persistent-vector-pt-1 > <http://hypirion.com/musings/understanding-persistent-vector-pt-1> > The reason why people use immutable.js and mori in JavaScript and why all > default data structures in Clojure are based on Bagwell/Hickey algorithms, is > that these libraries provide **efficient** way to manipulate immutable > datastructures in a **convenient** way. > > And there is growin React community that would like to use immutable.js as > primary data structures in their programs. > > https://facebook.github.io/react/docs/advanced-performance.html#immutable-js-to-the-rescue > > <https://facebook.github.io/react/docs/advanced-performance.html#immutable-js-to-the-rescue> > So, let me sum up: > > There is a growing functional/reactive community amongst JavaScript > programmers. Ones of key building blocks of functional programming are > **efficient** immutable datastructures. These are not native in JavaScript. > > Currently the only drawback of using immutable datastructures in javascript > is how cumbersome it is to use them. And part of the reason is that > destructuring does not work and we have to write: > > ``` > > const first = book.getIn(['author', 'name', 'first']) > > const last = book.getIn(['author', 'name', 'last']) > > const age = book.getIn(['author', 'age']) > > ``` > > In particular, it is no longer to write > > let {a: x, b: y} = unMap(map) > > as you can today, then it would be to move the transformation to the pattern: > > let Map({a: x, b: y}) = map > > But this does not work for nested structures. Like on the example above. > > Have I made my motivations more clear now? > > Thanks for reading this horribly long email:) > > Cheers, > > > @samuha <https://twitter.com/samuha> (+421 949 410 148) > > skype: samuelhapak > > Check my availability at https://freebusy.io/[email protected] > <https://freebusy.io/[email protected]> > > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > @samuha <https://twitter.com/samuha> (+421 949 410 148) skype: samuelhapak Check my availability at https://freebusy.io/[email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
