TC39 General
2021-06-10
plaintext logs
prev next
source on github
02:37
<sideshowbarker>
Any input any of might y’all might have on https://github.com/mdn/content/issues/309 would be welcome
02:38
<sideshowbarker>
The OP asserts “Static class fields should not yet be documented without a disclaimer.”
02:42
<sideshowbarker>

…and suggests that to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static we add the same warning text that the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields article has — which is:

This page describes experimental features.

Both Public and private field declarations are an experimental feature (stage 3) proposed at TC39, the JavaScript standards committee.

Support in browsers is limited, but the feature can be used through a build step with systems like Babel. See the compat information below.

02:43
<sideshowbarker>
adding that sounds reasonable to me
02:43
<sideshowbarker>
is there any reason I shouldn’t?
02:45
<sideshowbarker>
I see that https://tc39.es/proposal-class-fields/#prod-FieldDefinition is still at Stage 3, so that assertion is accurate at least
02:46
<sideshowbarker>

further though, the OP says:

Yes, static methods are standardised just fine, but https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static unfortunately describes all kinds of static members, both methods and "properties" (it doesn't even use the term "public field"). It doesn't even link the pages about method definitions or public class fields.
That's why we need a banner on this page as well (of course, only for static fields). Students are already confused because they read MDN but then their ES2020 tooling won't accept the syntax they've seen.

02:48
<bakkot>
The proposal text is out of date: it's stage 4, and landed in the specification
02:48
<sideshowbarker>
aha
02:48
<sideshowbarker>
OK, I had vaguely remembered that it landed in the spec
02:49
<bakkot>
https://github.com/tc39/ecma262/pull/1668 is the PR
02:49
<sideshowbarker>
thanks much
02:50
<sideshowbarker>
well then, incidentally, there remains this general problem it’s hard for me and others like me to know when a proposal has finally been merged into the spec
02:51
<bakkot>
the canonical way is to check https://github.com/tc39/proposals
02:51
<bakkot>
in particular, see https://github.com/tc39/proposals/blob/master/finished-proposals.md
02:51
<sideshowbarker>
OK
02:52
<sideshowbarker>
yeah but even though I actually knew that, for some reason I consistently fail to check it
02:52
<sideshowbarker>
I keep re-learning this
02:52
<sideshowbarker>
maybe it’ll eventually stick
02:53
<sideshowbarker>
OK, well I will update both the MDN warning text and also https://github.com/mdn/browser-compat-data (which is what the Specification section is now generated from)
02:55
<DerekNonGeneric>
sideshowbarker: navigating the proposals in the various stages is probably easiest by using the footer of the tc39 site (https://tc39.es/)
02:55
<sideshowbarker>
as far the content of the article itself, I guess it would be worthwhile to refine that content to use the correct terms — e.g., public field — and to put one separate section for static methods, and another for fields (and add the suggested links)
02:56
<bakkot>
yeah, so there's a matrix of stuff: [static, instance] x [public, private] x [field, method, accessor]
02:56
<bakkot>
prior to #1668 landing, the only part which was filled out was [static, instance] x [public] x [method/accessor]
02:56
<bakkot>
now it's completely filled out
02:57
<sideshowbarker>
OK
02:57
<bakkot>
I'm not sure what the best way to present that matrix is, though
02:57
<bakkot>
(s/matrix/cartesian product/)
02:58
<sideshowbarker>
yeah I guess it’s just relatively complicated and kind of an information-design challenge — as far as documenting it in MDN
02:59
<sideshowbarker>
anyway, if anybody is interested in putting together a PR for resolving the more-substantive part of https://github.com/mdn/content/issues/309, that would be very welcome
02:59
<sideshowbarker>
otherwise I guess I will circle back around to it myself at some point later
03:28
<sideshowbarker>
oh hey bakkot I just noticed one thing other worth mentioning to you and here — 
all the Specification links to the ES spec in MDN now reference the multipage spec
e.g., at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static#specifications
03:32
<bakkot>
nice!
08:47
<sideshowbarker>

crazy idea for y’all to consider: after a proposal has gone through all the stages and gets merged into the spec, change the body start tag in the HTML source of the proposal to this:

<body onload='(function() { location.href = "https://tc39.es/ecma262/multipage/" + location.hash; })()'>
08:48
<sideshowbarker>

…alternatively, to the full spec:

<body onload='(function() { location.href = "https://tc39.es/ecma262/" + location.hash; })()'>
08:49
<sideshowbarker>
…in other words, make the proposal document redirect to the corresponding fragment in the ES spec
09:05
<sideshowbarker>
sideshowbarker: navigating the proposals in the various stages is probably easiest by using the footer of the tc39 site (https://tc39.es/)
I see now — thanks!
09:08
<sideshowbarker>
but it might help some of that footer also included all the merged proposals too
I realize that’s a longer list — but it could all be put into collapse details element
20:43
<DerekNonGeneric>
well then, incidentally, there remains this general problem it’s hard for me and others like me to know when a proposal has finally been merged into the spec
sideshowbarker: i know we had a similar confusion come up when the footer had just landed, so perhaps some disambiguation could be of some use here https://github.com/tc39/tc39.github.io/issues/217
20:46
<sideshowbarker>
created an issue at https://github.com/tc39/proposals/issues/360 for my proposal-redirect idea
20:49
<DerekNonGeneric>
oh, hmm interestingg
21:55
<sideshowbarker>
looking at https://github.com/mdn/content/issues/5875
21:56
<sideshowbarker>
per-spec, new Uint8Array("nope") should not throw, right?
22:00
<bakkot>
correct
22:01
<bakkot>
when called with a non-object it coerces the argument to an integer, which defaults to 0 for anything which would be NaN
22:02
<sideshowbarker>
OK, thanks
22:02
<bakkot>
I wonder if that page was written back when it was a Khronos spec
22:03
<sideshowbarker>
ah yeah that would make sense
22:03
<sideshowbarker>
I had forgotten the genesis for TypedArray
22:03
<sideshowbarker>
but incidentally, what does the requirement in https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray% actually apply to?
22:04
<bakkot>
invoking rather than constructing with new
22:04
<sideshowbarker>
aha, yeah — thanks again
22:04
<bakkot>
or, wait
22:04
<bakkot>
sorry
22:05
<bakkot>
this one is for calling the actual TypedArray object
22:05
<bakkot>
which is Uint8Array.prototype
22:05
<bakkot>
so this is what happens if you new Uint8Array.prototype or whatever
22:05
sideshowbarker
looks again
22:05
<sideshowbarker>
ah OK
22:05
<bakkot>
er, sorry, Uint8Array.prototype.__proto__
22:05
<bakkot>
or something like that
22:05
<bakkot>
I have to page this in
22:06
<bakkot>
Uint8Array.prototype.__proto__.constructor
22:06
<bakkot>
there we go
22:06
<bakkot>
so that error is for Uint8Array.prototype.__proto__.constructor() and new Uint8Array.prototype.__proto__.constructor()
22:07
sideshowbarker
prepares a PR for removing the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Typed_array_invalid_arguments article
22:21
<bakkot>
sideshowbarker: btw, my matrix logger will let you link to ranges, same as with github
22:22
<bakkot>
just shift-click the end of the range
22:27
<sideshowbarker>
sideshowbarker: btw, my matrix logger will let you link to ranges, same as with github
beautiful — thanks for the heads-up