Code samples #96
Code samples #96
Conversation
_data/stage3.yml
Outdated
| @@ -225,6 +254,15 @@ | |||
| champions: | |||
| - Jordan Harband | |||
| - Kevin Gibbons | |||
| example: > | |||
| const entries = new Map([ | |||
There was a problem hiding this comment.
i think it might be a bit confusing to call a Map entries; it's certainly iterable for entries, but that's not exactly the same thing. maybe call it iterableOfEntries?
There was a problem hiding this comment.
Or, should we use [['cat', 'dog'], ['life', 42]]?
There was a problem hiding this comment.
That could work too - but it's also nice to show that you can do it with a Map. Maybe both examples?
There was a problem hiding this comment.
Will just rename it to iterableOfEntries, too many examples could be confusing?
|
These look great! Thanks for contributing. The examples make this page much more descriptive. Let's see if we can get reviews from the proposal champions. Do you think you could look up who each of them is and @-mention them? |
| // ↪ 9007199254740991n | ||
|
|
||
| const hugeButString = BigInt('9007199254740991'); | ||
| // ↪ 9007199254740991n |
There was a problem hiding this comment.
For BigInt, I'd prefer we contrast the Number behavior with the BigInt behavior, and not include a use of the BigInt constructor on a Number (as that could lead people to use a buggy pattern with rounding).
There was a problem hiding this comment.
Hm, I'm not sure what you mean @littledan. I think showing how the constructor works with a Number literal is pretty necessary, in general, but if you mean just for the case of this example, we could definitely use something like this instead:
const x = Number.MAX_SAFE_INTEGER;
// ↪ 9007199254740991, this is 1 less than 2^53
const y = x + 1;
// ↪ 9007199254740992, ok, checks out
const z = x + 2
// ↪ 9007199254740992, wait, that’s the same as above!
const a = BigInt(Number.MAX_SAFE_INTEGER);
// ↪ 9007199254740991n, this is 1 less than 2^53, and also a BigInt
const b = a + 1n;
// ↪ 9007199254740992n, checks out, still a BigInt
const c = a + 2n
// ↪ 9007199254740993n, now that's what I wantThere was a problem hiding this comment.
In general, I am afraid that people could develop false expectations about how the BigInt constructor works, and try to use it with large number literals. I have already gotten a few "bug reports" about this. I am not sure how we could use code samples to avoid the issue; I am not an expert here.
There was a problem hiding this comment.
So I think this with maybe a final line showing it re-rounded? There is nothing bad about showing people how the BigInt constructor is used — not everyone is going to use literals, right?
To some extent, I think we are going to have to accept that people are going to make some mistakes as they get used to new functionality — and then it will become just a known fact about Javascript. To me that's as expected. But then, I also don't get "bug report"s.
There was a problem hiding this comment.
Yeah, I just want to emphasize the happy path. Do you see a reason why someone should use the BigInt constructor together with a Number literal? I was imagining that that was subsumed by BigInt literals, but maybe I am missing something.
There was a problem hiding this comment.
I could image using the BigInt constructor with a number literal if you were programmatically piping data into some calculations with known BigInts, where the literal wouldn't really work. E.g.
let nums = [4, 10, 17, 22] // pretend these come from some API you do not control
let bigFriend = 9007199254740992n
nums.map((n) => bigFriend + num) // would throw
nums.map((n) => bigFriend + BigInt(num)) // would not
_data/stage3.yml
Outdated
| example: > | ||
| [1, [2, [3]]].flat(Infinity); // [1,2,3] | ||
|
|
||
| [2, 3, 4].flatMap((x) => [x, x * 2]); // [[2, 4, 3, 6, 4, 8] |
There was a problem hiding this comment.
It’d probably be helpful to include a flatMap example that illustrates that it has a depth of 1
There was a problem hiding this comment.
This output looks good to me.
| { | ||
| 0: "Hello ", | ||
| 1: "Hello" | ||
| index: 0, |
There was a problem hiding this comment.
These match objects now also contain a “groups” property (which is undefined if there’s no named captures)
There was a problem hiding this comment.
also I’m not sure how to illustrate better that these are not objects, but arrays with string properties
There was a problem hiding this comment.
I’m the champion of matchAll, and @mathiasbynens was the champion of named capture groups.
There was a problem hiding this comment.
also I’m not sure how to illustrate better that these are not objects, but arrays with string properties
I’ve always done it this way, which matches the Node.js REPL:
…
[
'DEADBEEF',
index: 19,
input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
]
…
The only downside is that it’s not valid JavaScript syntax.
|
@littledan Thank you, I had a list of @'s not sure if I can reuse them here. |
|
@littledan @ljharb anything else pending on this PR? I was planning to edit this PR to adhere to issues#66 what say? |
|
Hey folks, I updated this to remove stage 4 proposals |
|
This looks good otherwise |
|
LGTM |
Code samples for few of the proposals.
P.S: I am having issues running the docker, pinged on IRC.