Stage 0 Proposal: Extensible Collection Literal

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Stage 0 Proposal: Extensible Collection Literal

Alexander Jones
As a follow-up to https://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.)


Thanks

Alex

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Stage 0 Proposal: Extensible Collection Literal

Naveen Chawla
I don't like the # symbol there.

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

On Sun, 30 Jul 2017 at 02:51 Alexander Jones <[hidden email]> wrote:
As a follow-up to https://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.)


Thanks

Alex
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Stage 0 Proposal: Extensible Collection Literal

Viktor Kronvall
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 <[hidden email]>:
I don't like the # symbol there.

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

On Sun, 30 Jul 2017 at 02:51 Alexander Jones <[hidden email]> wrote:
As a follow-up to https://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.)


Thanks

Alex
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Darien Valentine
In reply to this post by Alexander Jones
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Isiah Meadows-2

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Alexander Jones
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Isiah Meadows-2

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Alexander Jones

On 30 July 2017 at 17:13, Isiah Meadows <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Naveen Chawla
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 <[hidden email]> wrote:

On 30 July 2017 at 17:13, Isiah Meadows <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Alexander Jones
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 <[hidden email]> 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 <[hidden email]> wrote:

On 30 July 2017 at 17:13, Isiah Meadows <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss