> On 21.7.2015, at 9:34, Andreas Rossberg <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
