Which is why I said there should be an issue filed there for it, so it *does* get considered. My point was that we shouldn't get too in depth independently of that proposal.
Currently, that strawman is so incomplete in its current state it doesn't even fully cover existing destructuring yet (like nested patterns). That's where I was coming from when I recommended delaying until the pattern matching proposal gets to a state we can consider it. On Sun, Jul 30, 2017, 12:04 Alexander Jones <[email protected]> wrote: > Hey Isiah > > Good shout - definitely worth connecting pattern matching/destructuring to > the same concept. > > Let's assume `#{}` is kept, for the avoidance of bikeshedding: > > ```js > const map = Map#{42: "the answer"}; > > const #{42: fortyTwo} = someMap; > // or? > const {[42]: fortyTwo} = someMap; > console.log(fortyTwo); // "the answer" > ``` > > And presumably: > > ```js > match (map) { > #{42: _}: `42 is ${_}`, > else: `who knows?`, > } > ``` > > I'd be wary of just powering ahead with pattern matching /without/ > considering generalised mapping/sequence syntax... > > On 30 July 2017 at 16:41, Isiah Meadows <[email protected]> wrote: > >> How about for now, let's hold off on anything concrete until after the >> pattern matching proposal gets to a point we can model the syntax and >> semantics after that. There's quite a bit of overlap in terms of behavior, >> too, which is more reason to consider this together with it. >> >> https://github.com/tc39/proposal-pattern-matching >> >> (I don't believe there's an issue over there for potential future >> expansion to extensible destructuring assignment, but there should be.) >> >> On Sun, Jul 30, 2017, 11:34 Darien Valentine <[email protected]> >> wrote: >> >>> While static analysis is one advantage, there are additional reasons for >>> this to be a syntactic proposal. A helper method like `Map.fromObject` >>> could indeed be a useful addition to the language (though it is simple >>> enough to do already: `new Map(Object.entries(obj))`) — however that does >>> not work for maps whose keys are not also valid property keys. >>> >>> In general I’m in the less-new-syntax camp, but I find this idea >>> intriguing. My initial impression is that it’s fairly convincing, mainly >>> because my (purely anecdotal) experience is that it is an attempt to solve >>> a real problem — many devs seem to be reluctant to use `Map` and `Set`, >>> despite knowing they exist and are sometimes more appropriate models, and I >>> think it is in part due to their "second class" nature; in ES folks are >>> accustomed to "seeing" data structures. Similarly there is reluctance to >>> work with subclasses of data structures, which are put on equal-footing by >>> this proposal. >>> >>> The `#` is indeed ugly, but the particular symbol I imagine is highly >>> bikesheddable and consideration of it could probably be deferred till it’s >>> determined whether the core ideas of the proposal represent a worthwhile >>> addition. >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
