Extensible destructuring proposal

[Samuel Hapák]

> On 21.7.2015, at 9:34, Andreas Rossberg <rossberg at google.com> wrote:
> 
> People reading code will (rightfully) expect destructuring to be syntactic sugar for property access. I don't think it's worth breaking that equivalence. If you want user-defined patterns then they should be syntactically distinct from existing forms.

This is already not true for array destructuring. You can use it with any iterables, not only with arrays.

`@@get` should be implemented only by “Map like” data structures. Destructuring is usually used to extract deeply nested data from `Object`. I find hard to believe that someone would deliberately use destructuring on `Map` or similar structure to extract methods:

```
// very strange use of destructuring, don’t believe anyone is doing that
const {get, has, set} = myMap // instance of Map()
```

Much more common use case is that you have nested structure of “Map like” structures and want to easily retrieve values.

Btw. this change is backward compatible, because it does not change behavior of existing code. It just gives you ability to provide users with new datastructures.

> 
> Also, destructuring patterns are meant to match, and be the logical inverse of, literal syntax. Consequently, from my perspective at least, extensible destructuring would require first introducing extensible literal syntax in a symmetric manner. I think it would be unnecessarily surprising if for random patterns they didn't match up (worse, if you cannot even tell the meaning syntactically, but it depends on whatever object you happen to get).
As I have pointed out, this is not true for iterable destructuring.

```
[a, b, c] = someIterable; // someIterable does not have to be Array
```

This can be similarly surprising:
`someIterable[0] !== a // true`

Thanks,

Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3589 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150721/c141f34e/attachment.p7s>