New API with getOrInsert and getOrInsertComputed #58
Conversation
This updates the design to match what was presented to committee at the October 2024 plenary. I am becoming champion of the proposal with the students at the University of Bergen as co-authors, and the previous champion and author are noted as no longer actively involved in the proposal. The naming of the methods is still up for discussion, I plan to open an issue to discuss options once this pull request is merged.
README.md
Outdated
| @@ -1,129 +1,126 @@ | |||
| # `Map.prototype.emplace` | |||
| # `Map.prototype.getOrInsert` | |||
There was a problem hiding this comment.
Please choose a proposal name that doesn't tie us to a specific solution. This is an example of the issue, as the proposal problem space hasn't changed, but now we're having to rename the proposal. I am usually pretty strict about this during Stage 1 presentations, but this proposal might predate me being so diligent.
There was a problem hiding this comment.
Completely agree, would Map Default Values be ok?
There was a problem hiding this comment.
Yeah that sounds good to me. That would also permit solutions we explored (and didn't like) like initialising a Map with a default value.
There was a problem hiding this comment.
I think matching the repository name "upsert" is fine: https://en.wiktionary.org/wiki/upsert
To insert [rows into a database table, or more generally items into a collection] if they do not already exist, or update them if they do.
There was a problem hiding this comment.
I think "upsert" is a great proposal name regardless of the eventual solution.
There was a problem hiding this comment.
It does? Points 1 and 4 combined are "get or insert" and 2 and 4 combined are "get or insert computed".
I definitely agree on naming broadly, I just think upsert is sufficiently broad.
There was a problem hiding this comment.
In my above comment, I was referring to an API like new Map(..., { default: () => 0 }), called DefaultMap in Dan's slides, referencing Python's defaultdict.
There was a problem hiding this comment.
I think "upsert" covers that approach at least as well as "Map Default Values" covers map.getOrInsert(key, initialValue) (i.e., not perfectly but good enough to make sense).
There was a problem hiding this comment.
I'm ok with either option, neither is perfect, the one advantage of upsert is that it matches the repository name which might help people find things.
README.md
Outdated
| @@ -1,129 +1,126 @@ | |||
| # `Map.prototype.emplace` | |||
| # `Proposal Upsert` | |||
There was a problem hiding this comment.
| # `Proposal Upsert` | |
| # Proposal Upsert |
There was a problem hiding this comment.
WFM. I'm not gonna do a review of the spec text until after Stage 2. I would like to see an API name bikeshedding issue at some point though. There's lots of prior art for us to take naming inspiration from and hopefully make it intuitive/unsurprising for as wide a group as possible.
Thanks. I was planning to open an issue to bikeshed the names as soon as this is merged. |
This updates the design to match what was presented to committee at the October 2024 plenary. I am becoming champion of the proposal with the students at the University of Bergen as co-authors, and the previous champion and author are noted as no longer actively involved in the proposal.
The naming of the methods is still up for discussion, I plan to open an issue to discuss options once this pull request is merged.