Discuss
  • Stage 0 Proposal: Extensible Collection Literal

Stage 0 Proposal: Extensible Collection Literal

# Alexander Jones (7 years ago)

As a follow-up to esdiscuss.org/topic/map-literal I've finally (2 years? Really?) written up a proposal for extensible collection "literal" syntax (for Map, Set, Immutable.List, etc.)

alex-weej/es-extensible-collection-literal

Thanks

Alex

# Naveen Chawla (7 years ago)

I don't like the # symbol there.

I would prefer something like Map.fromObject({ 'myKey': {}, myKey2: [] }); etc.

# Viktor Kronvall (7 years ago)

One of the stated advantages of the proposal is that because it is syntax driven it allows for static error messages limiting some bugs.

Using a method would not give the same degree of certainty of correctness as that would require assertions to be deferred to runtime, since EcmaScript is not statically typed.

I think there could be other alternatives for the operator but I agree with the original proposal that it is good to use syntax for this use case.

2017年7月30日(日) 9:06 Naveen Chawla <naveen.chwl at gmail.com>:

# Darien Valentine (7 years ago)

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. FWIW though, one alternative might be no symbol; Map {} (with a "No Line Terminator Here") is currently invalid syntax.

# Isiah Meadows (7 years ago)

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.

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.)

# Alexander Jones (7 years ago)

Hey Isiah

Good shout - definitely worth connecting pattern matching/destructuring to the same concept.

Let's assume #{} is kept, for the avoidance of bikeshedding:

const map = Map#{42: "the answer"};

const #{42: fortyTwo} = someMap;
// or?
const {[42]: fortyTwo} = someMap;
console.log(fortyTwo);  // "the answer"

And presumably:

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...

# Isiah Meadows (7 years ago)

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.

# Alexander Jones (7 years ago)

tc39/proposal-pattern-matching#47

# Naveen Chawla (7 years ago)

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

const map =
    #
        {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.

# Alexander Jones (7 years ago)

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