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]> 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]







Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to