https://github.com/tc39/proposal-pattern-matching/issues/47
On 30 July 2017 at 17:13, Isiah Meadows <[email protected]> wrote: > 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
