Custom key equality is a very specific case of the generality that this proposal supports. Maybe that's not clear enough in the text?
Realistically, that "key" is useless because it is mutable. Changing one of its properties would have no way of informing the owning map(s!) and thus the only immutable property of it, appropriate for use in a map, is its identity. (You probably want Immutable.Record for this purpose.) There are a couple of similar examples in the text but I might remove them as they are more of a distraction. Thanks Alex On Mon, 31 Jul 2017 at 06:40, Naveen Chawla <[email protected]> wrote: > If ES ever introduces a way of customizing key equality in Maps, then the > literal syntax would have to be updated to include that "comparator" > function. > > Also, curly braces with colons that separate the keys and values currently > denote objects, whose keys are limited in type. > > Maps can have objects, booleans etc. as keys, so having `#{ true: "Yes", > false: "No" }` would be either ambiguous or confusing. > > So I'm not totally comfortable with curly braces or colon in the syntax at > all. Suppose you have a key-value pair: KEY `{resourceType:"File", > resourceCategory: "Audio"}` with VALUE `()=>"Audio file"` I would rather > see something like > > ``` > # > {resourceType:"File", resourceCategory: "Audio"} -> ()=>"Audio file" > # > ``` > > than trying to shoehorn the map syntax to share the existing object > literal syntax. > > Personally I don't see the value in using maps at all yet until custom key > equality can be trivially provided to a map. > > On Sun, 30 Jul 2017 at 23:53 Alexander Jones <[email protected]> wrote: > >> 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 >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
