Extensible destructuring proposal
Matúš Fedák
mfedak at gmail.com
Wed Jul 22 14:52:14 UTC 2015
>
> I think the example actually reveals a deeper issue with the motivation:
> the desire to destructure maps like here is rooted in a category error.
> Destructuring is designed to apply to objects from the program domain,
> while maps are typically meant to encode data from the problem domain. Or,
> in other words: destructuring is only useful when you know the keys at
> programming time (i.e., statically). But if that is the case, there is
> rarely a good reason to use a map. /Andreas
- Most programs acquire, transform, store, search manage, transmit data
- Data is raw, immutable information
- Many langs turn into something much more elaborate - with types,
'methods' etc
esp. OO conflate process constructs and information constructs
Rich Hickey, the author of Clojure programing language
reference : https://youtu.be/VSdnJDO-xdg?t=811
What is the difference between object from domain and data from domain? If
I get a json (from some service) and I statically know what keys it has I
have an ability to destructure it. But if I convert JSON to an immutable
structure (or to a Map) I'm losing this ability somehow. That's strange,
since I didn't change abstraction, only actual implementation of the
underlying data structure.
```
// this is possible because json return object and array like data structure
const {name, time} = getJsonMap();
// this is not possible because now it will be stored as ImmutableMap
const {name, time} = Immutable.fromJS(getJsonMap());
// but if I would have an array then this is currently possible
const [first, second] = getJsonArray();
// and also this is possible because array destructuring work with
iterables and immuatableArray can be iterated
const [first, second] = Immutable.fromJS(getJsonArray());
```
To sum it up, I would be really happy to see generalization of object
destructuring. I don't have a strong opinion about original proposal and
Scala-flavoured one. I consider array proposal general enough (since your
custom object can support it). Only debatable advantage of Scala-proposal
is that you don't lose ability to destructure objects if they define their
custom destructuring logic.
```
// Original proposal
let {a, b} = new Map([["a", 2], ["b": 3]]); // this will be completely ok
let {size} = new Map([["a", 2], ["b": 3]]); // this will not be possible
// Scala proposal
let Map{a, b} = new Map([["a", 2], ["b": 3]]); // this will be completely ok
let {size} = new Map([["a", 2], ["b": 3]]); // this will be also doable
```
However, I don't see a point in having possibility to destructure functions
from Map or ImmutableMap or other primitives that decide to implement
custom object-destructuring logic.
Maty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150722/4b276b63/attachment.html>
More information about the es-discuss
mailing list