| 01:25 | <rbuckton> | erights: During plenary you asked if there was anything outside of export/export default that would make the Function.prototype.toString of a class non-eval-able given sufficient context for identifiers. I said no, but there is, to a degree. Any computed property name can contain await or yield, making it non-eval-able by default without having to wrap the string in something like an "async function * () { ... }" first. The context outside of the eval itself is not sufficient to support await and yield on their own. While this is unlikely to occur regularly, it is perfectly legal JS. |
| 04:53 | <HE Shi-Jun> | lol that is a previously unmentioned fourth option, i guess |
| 05:01 | <HE Shi-Jun> |
|
| 14:34 | <Rob Palmer> | Good morning, all. Plenary begins in 26 minutes time. |
| 14:35 | <Rob Palmer> | Please be aware that Import Assertions continuation is scheduled in the first (AM) slot (the final 60min) |
| 15:06 | <HE Shi-Jun> | Have we started? |
| 15:07 | <bakkot> | HE Shi-Jun: yes |
| 15:07 | <HE Shi-Jun> | I hear nothing... weird |
| 15:07 | <bakkot> | jitsi has some bugs... |
| 15:08 | <HE Shi-Jun> | oh, so what can i do ? reconnect? |
| 15:09 | <littledan> | yes, please refresh if you don't hear anything |
| 15:09 | <HE Shi-Jun> | reconnect and now I see the screen. |
| 15:09 | <Rob Palmer> | please wipe your browser site cache and restart the browser |
| 15:13 | <littledan> | Note, we can reuse the WHATWG infra spec (or copy it) for this editorial issue |
| 15:13 | <littledan> | I agree with avoiding actual Maps (since it is annoying to check whether this leaks) |
| 15:14 | <bakkot> | infra spec is a little bit up in the air on this particular thing at the moment https://github.com/whatwg/infra/pull/451 |
| 15:15 | <bakkot> | might be fixed by the time it's relevant |
| 15:17 | <Michael Ficarra> |
|
| 15:17 | <Michael Ficarra> | this design is consistent with those goals |
| 15:20 | <littledan> | love how the notetakers have so little to correct that we're just falling over each other to put the names in |
| 15:23 | <Michael Ficarra> | Justin Ridgewell: we don't want to add the hidden intrinsics to the global because almost nobody cares about them and they just add clutter |
| 15:23 | <Justin Ridgewell> | But they can be lazy loaded |
| 15:24 | <shu> | bakkot: WDYT my concrete alternative if you also do something similar? |
| 15:24 | <Justin Ridgewell> | This trades lazy loading for eager, seems like he'll shoot himself in the foot to get this? |
| 15:24 | <Michael Ficarra> | we talked about that with some of the new hidden intrinsics in iterator-helpers and the whole committee wanted to not add them |
| 15:24 | <shu> | Michael Ficarra: i like justin's suggestion actually |
| 15:24 | <shu> | that means the only thing we need to add here is just the string iterator for all intrinsics |
| 15:24 | <shu> | like we gotta put them somewhere if we agree to this use case |
| 15:25 | <Michael Ficarra> | shu: you pull them out of the getIntrinsic function |
| 15:25 | <ljharb> | my use case needs a direct way to access one, not an iterator for all of them - the retrieval use case |
| 15:26 | <msaboff> | Please add your name, abbreviation and member organization to today's minutes. |
| 15:26 | <shu> | Michael Ficarra: i'm saying i do not want the getIntrinsic function |
| 15:26 | <shu> | only a getHiddenIntrinsic function |
| 15:26 | <shu> | memory overhead of implementing getIntrinsic remains something v8 does not want |
| 15:29 | <Michael Ficarra> | it makes it easier for us because, instead of grabbing a few dozen references up front (and having to know which refs to grab), we just grab the one |
| 15:30 | <shu> | i don't think that clears the bar for adding to the language given other constraints |
| 15:30 | <shu> | that is, the niche use case thing |
| 15:30 | <shu> | but the hidden intrinsic use case thing sounds like an missing capability for the robustness people want |
| 15:31 | <Justin Ridgewell> | Sorry, what is the difference between getIntrinsic and just doing globalThis.previouslyHiddenIntrinsic.prototype.foo? |
| 15:31 | <Justin Ridgewell> | You would have to grab 0 references if we add to the global, right? |
| 15:31 | <Justin Ridgewell> | Just get it when you need it |
| 15:32 | <Michael Ficarra> | Justin Ridgewell: no, because someone who has run after us may have replaced those |
| 15:32 | <Justin Ridgewell> | And the behavior would be the same as accessing via getInrinsic('class.prototype.foo')? |
| 15:32 | <Justin Ridgewell> | But getIntrinsic can't return the original |
| 15:32 | <bakkot> | getIntrinsic would return the original unless it itself had been patched, that's the point of it |
| 15:33 | <Justin Ridgewell> | Yes, which was my point |
| 15:33 | <Michael Ficarra> | what was your point then? |
| 15:33 | <Justin Ridgewell> | Either the property has been modified and both getInrinsic and foo.bar.baz wouldn't get the original, or it's not modified and both would get the original |
| 15:33 | <Justin Ridgewell> | What's the point of getInrinsic if we add hidden intrinsics to the global? |
| 15:33 | <Justin Ridgewell> | I don't understand what's added |
| 15:33 | <Michael Ficarra> | if we have run first, we also have a reference to the "unmodified" getIntrinsic |
| 15:34 | <bakkot> | the scenario is:
|
| 15:34 | <bakkot> | right now, we have to cache everything we'll ever need in the first part |
| 15:34 | <Justin Ridgewell> | But getIntrinsic can't get a modified value? |
| 15:34 | <bakkot> | which is surprisingly tricky |
| 15:34 | <bakkot> | what does "can't get a modified value" mean? |
| 15:34 | <Michael Ficarra> | Justin Ridgewell: I don't know what that means |
| 15:34 | <ljharb> | you don't want it to get a modified value |
| 15:34 | <yulia> | and, just to reiterate -- you would want to be able to patch the cached values? is that right? |
| 15:34 | <HE Shi-Jun> | question: where is the link of current slide? |
| 15:34 | <yulia> | or you would be patching the globals |
| 15:35 | <Michael Ficarra> | yulia: both patching the globals and patching the getIntrinsic function |
| 15:35 | <bakkot> | We do also patch sometimes but that's both trickier and not always necessary |
| 15:35 | <bakkot> | there are a lot fewer things that we need to patch than there are things that we need to work |
| 15:35 | <yulia> | right so you want to control all access to for example Array.prototype.map |
| 15:35 | <Michael Ficarra> | yeah the things we patch is a much smaller set than the things we cache for protection |
| 15:36 | <Justin Ridgewell> | Justin Ridgewell: I don't know what that means Class.prototype.bar = null, then getInrinsic('class.prototype.bar') can't return the original bar value |
| 15:36 | <Justin Ridgewell> | That's what I mean |
| 15:36 | <Justin Ridgewell> | Well then what is the difference between just doing Class.porototype.bar when you need the value later? |
| 15:36 | <Michael Ficarra> | Justin Ridgewell: why? |
| 15:36 | <yulia> | yeah the things we patch is a much smaller set than the things we cache for protection |
| 15:36 | <Michael Ficarra> | Justin Ridgewell: it could have been written to by someone else |
| 15:36 | <Justin Ridgewell> | Because that's the semantics that Jordan outlined today?! |
| 15:36 | <bakkot> | yulia: like, for example, we had an annoying bug recently when some of our late-running code broke in a particular environment because the page had replaced the Response constructor with a version which was not spec-compliant |
| 15:36 | <bakkot> | we don't need to replace it |
| 15:37 | <bakkot> | but we do need to have the original one |
| 15:37 | <yulia> | right -- thats our use case, we always want the original |
| 15:37 | <yulia> | never the patched one |
| 15:37 | <Michael Ficarra> | would it be useful to have absolute access to a builtin |
| 15:37 | <yulia> | right, thats what i expected |
| 15:37 | <Michael Ficarra> | (because we do patch some things) |
| 15:37 | <yulia> | so if users start using an undeniable access to array then the things that you do patch would be at risk |
| 15:37 | <bakkot> | would it be useful to have absolute access to a builtin |
| 15:38 | <bakkot> | right, undeniable access for later-running code is a non-starter |
| 15:39 | <bakkot> | Well then what is the difference between just doing |
| 15:39 | <bakkot> | also, the size of the early-running code is more sensitive |
| 15:39 | <bakkot> | (since it needs to be loaded sync, during page load) |
| 15:39 | <Justin Ridgewell> | I understand that, you call getInrinsic('foo') later on |
| 15:39 | <yulia> | and just thinking out loud: the cached access would be for your code internally, not for the code that is used outside |
| 15:39 | <rbuckton> | If the Reflect object was actually about reflection, Reflect.getIntrinsic() would be a much better place than the global, IMO. I'd also prefer to see a getIntrinsicNames() function so as not to overload the return value of getIntrinsic(). |
| 15:39 | <yulia> | so we have two halves here: what you use internally, and what is used by other code externally that you want to patch (to make sure i have it right) |
| 15:40 | <michaelficarra> | yulia: yes, and sometimes those sets overlap |
| 15:40 | <bakkot> | yulia: right. the patching one isn't solved by this, but is also a much trickier thing to solve, I think |
| 15:41 | <yulia> | would they have access or knowledge of your cached getIntrinsic? because part of the risk is that getIntrinsic itself can be patched by later code right? |
| 15:41 | <bakkot> | any code which does patching will also need to patch getIntrinsic going forward, yes |
| 15:41 | <michaelficarra> | we have an in-house library for patching which has actually arrived at a pretty decent model; maybe we should propose adding it to the platform some time |
| 15:42 | <yulia> | i do think that this is a weird area right now, i just don't know exactly how to solve it because there are a few overlapping areas here |
| 15:42 | <yulia> | i kind of like shu's suggestion, because then you don't have two but it opens hidden intrinsics |
| 15:42 | <michaelficarra> | I think they're probably separable problems yulia |
| 15:43 | <yulia> | i'm not contesting that |
| 15:43 | <bakkot> | shu's solution does very little for us in particular because we're not currently doing the "traverse the whole global" thing for performance reasons, though it would be good for JHD and SES I guess |
| 15:44 | <shuyuguo> | bakkot: but you've also contended that your use case is niche enough that it doesn't need to be in the language IIRC? |
| 15:44 | <bakkot> | well, I would not champion this just for me |
| 15:44 | <bakkot> | I'm just saying if we add this I would definitely use it |
| 15:45 | <bakkot> | and it would eliminate... maybe 50% of the bug reports we get |
| 15:45 | <rbuckton> | Did we reach the end of the slides? |
| 15:45 | <shuyuguo> | i don't really understand |
| 15:45 | <shuyuguo> | why don't you traverse the global and get rid of 50% of the bug reports? |
| 15:45 | <shuyuguo> | like the alternative i suggested is functionally equivalent |
| 15:45 | <bakkot> | because that's too slow to do during page load |
| 15:45 | <michaelficarra> | shu: I don't think it's really that the use case is niche, just that it's currently very inconvenient today to be safe, so people decide to take the easier development and smaller file size trade-off |
| 15:45 | <shuyuguo> | except you're caching in user space instead of on every context |
| 15:46 | <shuyuguo> | so... the hypothesis is if you externalize that cost during snapshot creation for v8 that's okay |
| 15:46 | <bakkot> | that's the idea! |
| 15:46 | <shuyuguo> | okay |
| 15:46 | <shuyuguo> | nty |
| 15:46 | <yulia> | what i am getting lost on is what the advantage is here -- now you will patch in two places, and everyone who wants to patch will do so in two places. So you still need to run first, in any case |
| 15:46 | <bakkot> | right, we will always need to run first |
| 15:47 | <yulia> | i know that this is a different use case but its impacted by this api |
| 15:47 | <michaelficarra> | yulia: https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$Pcs3JQA_VGGAUGQTC_tbJdbIdfADtHrhsW_y7VjanW0?via=matrix.org&via=igalia.com&via=mozilla.org |
| 15:47 | <bakkot> | right now, our first-run code needs to know up front all of the things we will ever need, and cache them. this is both difficult to do and increases the cost of our first-run code, which is performance sensitive because it's running synchronously during page load. |
| 15:47 | <yulia> | so now you will cache by running first, but it feels like its almost an issue with layering where you want to be able to cascade definitions. don't know if that makes sense |
| 15:48 | <michaelficarra> | yulia: I don't understand |
| 15:48 | <yulia> | yulia: https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$Pcs3JQA_VGGAUGQTC_tbJdbIdfADtHrhsW_y7VjanW0?via=matrix.org&via=igalia.com&via=mozilla.org |
| 15:48 | <yulia> | i wasn't thinking of adding it to the global honestly i was thinking of shu's suggestion of a limited subset of apis |
| 15:48 | <michaelficarra> | yulia: no, this: |
| 15:49 | <haxjs> | too bad, i can't see the slide (seems network is so bad) |
| 15:49 | <michaelficarra> | yulia: it's the little green line on the left |
| 15:49 | <yulia> | I see |
| 15:49 | <yulia> | this is the caching case |
| 15:49 | <yulia> | yes i agree there |
| 15:49 | <rbuckton> | I'm not seeing the slides, should I restart Jitsi? |
| 15:49 | <nicolo-ribaudo> | I can't see them either now |
| 15:49 | <bakkot> | I just restarted and did not see them |
| 15:49 | <bakkot> | I think the problem is on jordan's end |
| 15:50 | <haxjs> | I restarted but still can't see |
| 15:51 | <haxjs> | I can see the slide now :) |
| 15:51 | <michaelficarra> | I think it was the "toggle tile view" at the bottom |
| 15:56 | <haxjs> | We need a namespace for reflection api which not relate to Proxy :) |
| 15:56 | <littledan> | The Reflect/Proxy trap correspondence was always sort of accidental/not the original intention, according to Dave Herman |
| 15:56 | <littledan> | I also like the idea of using the Reflect namespace |
| 15:57 | <haxjs> | maybe Introspect ? |
| 15:57 | <littledan> | it's a great way to move forward with stratificaiton, as Shu's saying! |
| 15:57 | <haxjs> | it's a great way to move forward with stratificaiton, as Shu's saying! |
| 15:58 | <rbuckton> | If we do allow more than just proxy traps on Reflect, I'm more than happy for us to be very selective about what we add to it. It's just a waste to leave it so limited. |
| 15:59 | <jridgewell> | For Node's memory concerns with eagerly grabbing intrinsics, isn't this just pushing the concern into V8 itself? |
| 16:00 | <jridgewell> | If V8 has to maintain the pointers to all of these intrinsic values for later retrieval, all those pointers still have to be maintained, just now by V8 |
| 16:00 | <shuyuguo> | Justin Ridgewell: that's exactly the tradeoff |
| 16:00 | <shuyuguo> | and what i said above, and bakkot confirmed |
| 16:00 | <shuyuguo> | that's not a tradeoff i want to make for all webpages |
| 16:00 | <shuyuguo> | and thus my alternative of just doing the hidden intrinsics |
| 16:00 | <shuyuguo> | and continue to leave the burden of caching to userland programs that need the robustness, which is rare |
| 16:01 | <jridgewell> | Ahh: https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$sHbpRAAb_qOusauVcfykPlOq9v1AMmPraH4FXwNhico?via=matrix.org&via=igalia.com&via=mozilla.org |
| 16:01 | <shuyuguo> | man matrix copy/paste sucks |
| 16:01 | <jridgewell> | Sorry, still trying to make breakfast so I'm missing a lot of the conversation |
| 16:03 | <michaelficarra> | the iterator method is only for the cache-the-world use case as far as I'm aware; we would have no use for it |
| 16:05 | <shuyuguo> | i have to drop for 30 minutes for mtg |
| 16:05 | <shuyuguo> | sorry, i need to be here for import assertions but i gotta drop |
| 16:05 | <littledan> | well, that is really too bad.... we could've shifted this around |
| 16:05 | <littledan> | we still maybe can |
| 16:24 | <yulia> | Ahh: https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$sHbpRAAb_qOusauVcfykPlOq9v1AMmPraH4FXwNhico?via=matrix.org&via=igalia.com&via=mozilla.org |
| 16:28 | <Michael Ficarra> | I absolutely do not buy the argument that developers are going to start relying on something because it is stage 3 without trying it out in any browser |
| 16:29 | <yulia> | chrome is currently shipping |
| 16:29 | <nicolo-ribaudo> | They can try it in Chrome |
| 16:29 | <yulia> | so for both firefox and safari this is an issue |
| 16:29 | <Justin Ridgewell> | Isn't this the "stage 3 shipability" discussion we had? |
| 16:29 | <yulia> | and puts pressure on us to ship our currently flagged versions |
| 16:29 | <Michael Ficarra> | ah I forgot about Chrome shipping |
| 16:32 | <ljharb> | Justin Ridgewell: eslint doesn't support anything til stage 4, do you mean like plugins and parsers? |
| 16:32 | <shu> | i am back |
| 16:33 | <Justin Ridgewell> | There are other parsers for eslint |
| 16:33 | <msaboff> | I'm somewhat surprised that the ecosystem has been built around a stage 3 proposal. |
| 16:33 | <ljharb> | that's what stage 3 means to the ecosystem - time to ship it and rely on it |
| 16:34 | <ljharb> | which is a big part of why it's a critical signal to send here by dropping it to stage 2 |
| 16:34 | <ljharb> | i don't think the likelihood of the syntax changing is affected, at all, by which stage the proposal is at. |
| 16:44 | <rbuckton> | We definitely have to relax the restriction, so the real questions are whether we should change the syntax to match the new semantics, and whether the need to investigate such a change over a period longer than a single plenary session is an indicator that we should demote the proposal to Stage 2? |
| 17:02 | <littledan> | is Guy cutting in and out for others? |
| 17:03 | <shu> | yes |
| 17:03 | <shu> | i can't understand really |
| 17:03 | <nicolo-ribaudo> | Yes |
| 17:03 | <yulia> | yeah i think ron has a good summary of where we want to go. when i brought up having consensus on the loosening -- it wasn't to scope the discussion at stage 2. it seemed like it was what we were agreeing upon and making it explicit would move us forward |
| 17:06 | <shu> | by what i'm hearing now i'm fine with the space we're at now, did i miss anything substantive in the first 30 minutes of this item? |
| 17:07 | <ryzokuken> | I think most of the first 30 minutes was about contemplating the different routes from a process perspective and defining a scope and timeline for the changes. I don't think you missed much if you're up to speed now. |
| 17:07 | <shu> | okay |
| 17:07 | <shu> | and it is fully clear to all parties that chrome is not unshipping during stage 2 demotion |
| 17:07 | <shu> | ? |
| 17:08 | <ljharb> | yep, that was mentioned a few times, here and in plenary |
| 17:08 | <shu> | okay, thanks |
| 17:08 | <msaboff> | Didn't Chrome initially ship when this was stage 2? |
| 17:09 | <shu> | most definitely not |
| 17:09 | <shu> | we don't ship any JS proposals during stage 2 |
| 17:09 | <msaboff> | When did Chrome ship? |
| 17:09 | <shu> | during stage 3, May 2021, version 91 |
| 17:10 | <littledan> | Thank you, ljharb and everyone else, for being so constructive in this discussion |
| 17:59 | <Rob Palmer> | We overran earlier so we will be starting at 5 mins past the hour (so 5 minutes time) |
| 18:00 | <yulia> | I'm done for the day, y'all. good luck with the rest of the agenda |
| 18:00 | <yulia> | iain is here for your mozilla concerns tho |
| 18:01 | <Rob Palmer> | Thanks for your support Yulia throughout the past days - it is appreciated. |
| 18:25 | <littledan> | PSA: You can also say "element" to refer to a field or method in a class |
| 18:26 | <ryzokuken> | is that a well-known term? |
| 18:26 | <littledan> | yes, it's used in the syntax |
| 18:26 | <ljharb> | i don't think the latter implies the former |
| 18:26 | <ljharb> | i'd guess it's intuitive but not well-known |
| 18:26 | <ryzokuken> | I've rarely heard that word used that way |
| 18:27 | <bakkot> | I am pretty sure the term was used in my OO classes back in school, but I don't know how common that is |
| 18:27 | <littledan> | I've just been told it'd be good to avoid the word combination "private member" and "element" is right there in spec jargon |
| 18:28 | <ljharb> | it makes perfect sense to me in this context, to be clear, i just don't think it's caught on much yet |
| 18:28 | <littledan> | (I've also switched from saying "hard private" to "strong encapsulation") |
| 18:28 | <ryzokuken> | yeah, same, but I guess we could all start using it like that and it could catch on |
| 18:28 | <Rob Palmer> | should it go in the how-we-work glossary? |
| 18:34 | <ljharb> | ryzokuken: how are we doing on the timebox? |
| 18:35 | <ryzokuken> | it runs until 39-40 |
| 18:35 | <ryzokuken> | so at most five more minutes |
| 18:37 | <Michael Ficarra> | who is the Chris that Ron is referring to? |
| 18:37 | <danielrosenwasser> | pzuraq |
| 18:38 | <pzuraq> | 👋 |
| 18:38 | <pzuraq> | I'm in another meeting at the moment, will be hopping back in the plenary in a sec |
| 18:39 | <danielrosenwasser> | (Chris Garrett) |
| 18:39 | <Michael Ficarra> | thx |
| 18:39 | <danielrosenwasser> | (I should fix up the notes from yesterday) |
| 18:51 | <Michael Ficarra> | ptomato: please add a conclusion to the last topic in the notes |
| 18:52 | <littledan> | I totally agree, .toString() as a big piece of motivation here is a bit bizarre |
| 18:52 | <iain> | littledan: Do you have a writeup of your ideas for improving decorator performance that I can point people at? |
| 18:53 | <littledan> | iain: Oh should we consider this issue still open? I mean, I really think those sorts of things wouldn't increase performance much in practice. |
| 18:53 | <littledan> | If we should consider them open, we should discourage TS from shipping |
| 18:53 | <littledan> | (no, I don't have a writeup) |
| 18:55 | <iain> | My personal take is that performance is currently probably fine, but I would like to run your suggestions past the person who's actually doing the implementation |
| 18:55 | <iain> | I can point him at the notes if necessary |
| 18:55 | <littledan> | the two things were, 1) make a token that you have to use at the declaration site to permit addInitializer [this got very strongly negative ergonomic feedback, and V8 at the time told us it wasn't necessary, though they haven't started implementing yet] 2) use a class instance instead of an object with closures for the get/set/has getters [last time we discussed that, there were some complicated requirements that Justin Ridgewell asked for, and I thought it'd be simpler to just use things this way] |
| 18:55 | <littledan> | is this dminor? |
| 18:55 | <iain> | Yeah |
| 18:55 | <iain> | dminor: ^ |
| 18:56 | <littledan> | Yeah, so, dminor if you want either of those changes, please raise an issue in the repo ASAP |
| 18:56 | <Justin Ridgewell> | Sorry, what did I ask for? |
| 18:56 | <littledan> | remember in the old stage 2 decorators, when they had a class representing the private name, and you said it had to be a frozen class? |
| 18:57 | <littledan> | making it a fresh object (as iain noted) was a way through without all that frozen class complexity |
| 18:57 | <Justin Ridgewell> | Ohh, yah, the reified private instance needed own properties and not prototype methods |
| 18:57 | <Justin Ridgewell> | Because otherwise you could intercept any reified private field |
| 18:57 | <littledan> | well, no, they were on the prototype but everything was frozen |
| 18:57 | <littledan> | anyway this was not for MM-style integrity but for some other practical integrity notion (where SES isn't used) |
| 18:58 | <Justin Ridgewell> | I think that was Domenic's suggestion, but it solved my concern either way |
| 18:58 | <littledan> | yeah I also disprefer instance methods |
| 18:58 | <littledan> | anyway that's why I stepped back and suggested what we have now |
| 18:59 | <littledan> | so this is that exact thing, where implementers realize, "oh, I see, now I have to do four fresh allocations per decorator invocation" (but I expect that's not going to be a bottleneck since its' not per instance) |
| 19:01 | <ljharb> | since angular won't be migrating, what's the scale of usage of legacy decorators excluding angular codebases? |
| 19:02 | <ljharb> | i would assume drastically smaller |
| 19:02 | <bakkot> | https://github.com/nestjs/nest also uses legacy decorators |
| 19:03 | <littledan> | https://github.com/nestjs/nest also uses legacy decorators |
| 19:04 | <littledan> | since angular won't be migrating, what's the scale of usage of legacy decorators excluding angular codebases? |
| 19:04 | <shu> | idk that's just what i heard from angular people |
| 19:04 | <shu> | they didn't want to update their videos |
| 19:05 | <shu> | sorry, not just heard, that's what they told me |
| 19:06 | <littledan> | ah OK I misunderstood |
| 19:06 | <bakkot> | I believe they've said they are not going to migrate in the absence of parameter decorators, which... uh, I am not going to say they will never happen, but if we were doing a temperature check on parameter decorators I would feel the need for a button to the right of "unconvinced" |
| 19:06 | <littledan> | I believe they've said they are not going to migrate in the absence of parameter decorators, which... uh, I am not going to say they will never happen, but if we were doing a temperature check on parameter decorators I would feel the need for a button to the right of "unconvinced" |
| 19:07 | <shu> | yes that too, they want that dependency injection |
| 19:07 | <danielrosenwasser> | we would expect libraries to ship these hybrid-decorator functions - especially in older versions to help with migrating |
| 19:07 | <ljharb> | does nest rely on parameter decorators? |
| 19:07 | <littledan> | we always said function and parameter decorators would come in a future phase, we just didn't expect class decorators to take so long |
| 19:08 | <bakkot> | does nest rely on parameter decorators? |
| 19:08 | <ljharb> | ok - what's the likelihood they'd migrate before angular then? |
| 19:08 | <bakkot> | nest I think is younger and consequently more willing to make breaking changes |
| 19:08 | <bakkot> | but again, that's a question for them |
| 19:09 | <ljharb> | gotcha |
| 19:09 | <shu> | I believe they've said they are not going to migrate in the absence of parameter decorators, which... uh, I am not going to say they will never happen, but if we were doing a temperature check on parameter decorators I would feel the need for a button to the right of "unconvinced" |
| 19:09 | <littledan> | why? |
| 19:10 | <shu> | they are not something i want to attach user-programmed logic to in any programming language |
| 19:10 | <shu> | and i think dependency injection is not a compelling use case |
| 19:10 | <shu> | perhaps there are other use cases |
| 19:10 | <rbuckton> | perhaps there are other use cases |
| 19:11 | <littledan> | I wonder if dependency injection in particular could be accomplished by... custom pattern matching handlers |
| 19:11 | <rbuckton> | I need to come back to this, but there are, yes. Function.prototype.toString of the constructor, which was terrible. |
| 19:12 | <bakkot> | two reasons for me:
|
| 19:12 | <littledan> | also FWIW Ember does dependency injection with field decorators, fitting into the pattern established here |
| 19:12 | <littledan> | and the usage of that seems a lot cleaner to me! |
| 19:13 | <shu> | very happy to let kevin do the arguing for me! |
| 19:13 | <bakkot> | also I'm going to have to drop off this meeting early, later all. my opinion on the export @dec topic is, I like the ES syntax better but am not so set on it that I want to fight about it more; the main outcome I would like to see is TS not shipping unflagged support for non-standard syntax |
| 19:13 | <rbuckton> | Parameter decorators are also useful for RRTI (runtime type information) and RTTA (runtime type assertions), as well as defining argument handling for routing (HTTP web apis, page routing in react) |
| 19:14 | <bakkot> | if that's achieved by changing the ES syntax I'm fine with it |
| 19:15 | <Rob Palmer> | Could someone write down the definition of "Option 3" here so we all know what it means. |
| 19:15 | <ljharb> | option 3 is "status quo" - which is, "decorators must come after export" |
| 19:18 | <littledan> | Parameter decorators are also useful for RRTI (runtime type information) and RTTA (runtime type assertions), as well as defining argument handling for routing (HTTP web apis, page routing in react) |
| 19:19 | <rbuckton> | I agree, but as i said those aren't the only cases. there are more but i'll follow up after plenary |
| 19:21 | <shu> | wait i'm confused by what daniel is saying |
| 19:21 | <shu> | why would people who like the stage 3 ordering make issues saying they like it? |
| 19:22 | <ljharb> | i think he's saying that even before this decision was made, nobody's been pushing for decorators-after |
| 19:22 | <littledan> | why would people who like the stage 3 ordering make issues saying they like it? |
| 19:22 | <ljharb> | altho that doesn't mean that, absent legacy usage, they'd disagree with the current ES syntax |
| 19:23 | <shu> | but that's not the opposite of disagreeing with the stage 3 syntax |
| 19:23 | <shu> | maybe people don't care either way? |
| 19:23 | <danielrosenwasser> | Nobody has come to TypeScript and said "this is bad, the stage 2/3 proposals are clearly heading in a better direction" with decorator ordering |
| 19:23 | <ljharb> | sure but that's because TS hasn't shipped it yet |
| 19:23 | <msaboff> | We run the risk that we are picking winners and losers. |
| 19:24 | <ljharb> | most people don't even know that "proposals" or "stages" are a thing |
| 19:24 | <shu> | danielrosenwasser: but... why is that evidence for preference for one way or the other? |
| 19:24 | <rbuckton> | I think its more to the point that, in the years since "decorators after export" was decided, the only feedback we received about changing the ordering prior to 5.0 was due to a Babel misconfiguration. |
| 19:24 | <HE Shi-Jun> | maybe people don't care either way? |
| 19:24 | <shu> | danielrosenwasser: it's also evidence for lack of preference, no? |
| 19:24 | <shu> | #69 on what repo? |
| 19:24 | <davethegr8> | https://github.com/tc39/proposal-decorators/issues/69 |
| 19:24 | <HE Shi-Jun> | on decorator repo |
| 19:24 | <rbuckton> | https://github.com/tc39/proposal-decorators/issues/69 |
| 19:25 | <danielrosenwasser> | The fact that people want an ordering option for Babel, but not for TypeScript, feels like evidence |
| 19:25 | <shu> | The fact that people want an ordering option for Babel, but not for TypeScript, feels like evidence |
| 19:25 | <danielrosenwasser> | But if your perspective is that that's "no preference", then it seems like either option I'm presenting here seem like reasonable directions |
| 19:26 | <shu> | i was saying the "we got 350k issues but stage 3 ordering ain't but 1" didn't seem like evidence for the opposite direction to me |
| 19:26 | <danielrosenwasser> | 35k, thankfully not 350k :D |
| 19:26 | <shu> | But if your perspective is that that's "no preference", then it seems like either option I'm presenting here seem like reasonable directions |
| 19:27 | <HE Shi-Jun> | I find this comment is especially useful to explain why we get stage 3 with the syntax which most decorator users don't like: https://github.com/tc39/proposal-decorators/issues/69#issuecomment-1411460427 |
| 19:27 | <HE Shi-Jun> | quote: "it seems superficially the people in this thread the most reliant on decorators are mostly in favour of before, but also have the highest stakes in keeping the proposal moving forward, giving 'before' up in the bargain" |
| 19:28 | <nicolo-ribaudo> | The fact that people want an ordering option for Babel, but not for TypeScript, feels like evidence The reason we have then given a default value to the option is that the proposal settled on decorators after export, but it was more out of inertia because no one wanted to continue that discussion (the decorators proposal has been really good at burning out people, me included) |
| 19:29 | <littledan> | I don't think this is the kind of situation where we need to position someone as the lone objector to option 1; we've heard from lots of people in committee today that they oppose option 1 |
| 19:29 | <littledan> | that said, I'd be happy with option 1 |
| 19:29 | <shu> | i'm happy with option 1 but let's hear from waldemar and did mark also object? |
| 19:30 | <shu> | well, not object, but voice anti-support previously |
| 19:30 | <shu> | "syntax must reflect semantics" IIRC |
| 19:30 | <littledan> | Yeah let's call on Mark and Waldemar |
| 19:30 | <littledan> | I don't think "people have objected to this in the past" is a valid reason to block |
| 19:31 | <ljharb> | no, but the reasons they (and i) objected in the past remain |
| 19:31 | <Willian Martins> | what is Option 3 btw? |
| 19:31 | <ljharb> | status quo |
| 19:31 | <littledan> | no, but the reasons they (and i) objected in the past remain |
| 19:31 | <ljharb> | focusing on those is the "mental model" discussion which is what led to all the debates years ago |
| 19:32 | <ljharb> | and i really don't want to reignite those debates |
| 19:33 | <nicolo-ribaudo> | what is Option 3 btw? |
| 19:38 | <littledan> | I'm sympathetic with ljharb's explanation for why option 2 is more "composable" than option 1--that you should be able to plop export on the beginning of any declaration |
| 19:38 | <littledan> | (but that shouldn't force us to option 3) |
| 19:38 | <ljharb> | agreed |
| 19:38 | <shu> | so what does @dec1 export @dec2 class {} mean? syntax error? |
| 19:39 | <ljharb> | oof, i'd hope so |
| 19:39 | <littledan> | IMO it's fine, they just apply in order |
| 19:39 | <shu> | o ok |
| 19:39 | <ljharb> | lol i guess that's an option too |
| 19:39 | <shu> | sick |
| 19:39 | <nicolo-ribaudo> | I know that temperature checks should be planned, but I would really like one now just to decide which option to procede with asking consensus on. I fear that no one would block the first thing we ask consensus on, even if the second one would make more people happy |
| 19:39 | <rbuckton> | so what does |
| 19:39 | <Rob Palmer> | Chris's reference to "the dress" is a picture when human eyes perceive the same image to be blue or gold. And both are correct. |
| 19:40 | <ljharb> | i think this is a case of "both are correct" but i'm not sure the dress is given one can sample pixel color values ;-) |
| 19:40 | <nicolo-ribaudo> | Chris's reference to "the dress" is a picture when human eyes perceive the same image to be blue or gold. And both are correct. |
| 19:40 | <Willian Martins> |
That makes me more sympathetic with option 3 |
| 19:40 | <shu> | the fact that it is a syntax error makes you more sympathetic? |
| 19:40 | <nicolo-ribaudo> |
|
| 19:41 | <rbuckton> |
|
| 19:41 | <Michael Ficarra> | who is William? they don't have an initialism |
| 19:41 | <Willian Martins> | Syntax error sound like a good compromising. |
| 19:41 | <ryzokuken> | Michael Ficarra: it's Willian Martins |
| 19:41 | <Michael Ficarra> | oh my bad, I misspelled |
| 19:42 | <shu> | oh man i was hoping for the high chaos option for applying in order |
| 19:42 | <shu> | i liked dan's answer there |
| 19:43 | <Willian Martins> | Hi I'm one of Netflix delegates. I'm mostly silent that is why you might not met me before. |
| 19:44 | <danielrosenwasser> | Which one? The one I stole from Curb Your Enthusiasm? |
| 19:44 | <littledan> | IMO it's fine for the export keyword to be in the toString |
| 19:44 | <littledan> | I just don't think this matters very much |
| 19:44 | <shu> | Which one? The one I stole from Curb Your Enthusiasm? |
| 19:44 | <littledan> | but also cutting off the decorators that come before the export seems fine |
| 19:44 | <ljharb> | i suppose that's an option too and would also meet my understanding of mark's concern |
| 19:45 | <littledan> | no, the one from littledan saying if you have a decorator in both positions it just applies them in-order |
| 19:45 | <danielrosenwasser> | Why? It should ping-pong |
| 19:45 | <danielrosenwasser> | Sorry, I'll move to TDZ |
| 19:46 | <littledan> | Overall you very much cannot go and re-eval toString and expect that to work, as rbuckton is saying. |
| 19:48 | <Michael Ficarra> | ryzokuken: I can no longer do notes. msaboff should be fine on his own though. |
| 19:48 | <ryzokuken> | it's almost done |
| 19:48 | <ryzokuken> | thanks to both of you |
| 19:48 | <ryzokuken> | the real MVPs today |
| 19:49 | <HE Shi-Jun> | so toString behave diff in before/after case? weird... |
| 19:49 | <leobalter> | option 2 but with or without the XOR positioning? |
| 19:49 | <ljharb> | with XOR |
| 19:49 | <leobalter> | can we clarify this in the meeting for the minutes? |
| 19:50 | <littledan> | This is a very satisfying ending to the meeting. Congratulations to the presenters! |
| 19:51 | <Michael Ficarra> | the transcription was fantastic, very few errors and very easy to edit |
| 19:52 | <Michael Ficarra> | they still have a bit of a hard time with non-native speakers, but then again so do I |
| 19:53 | <leobalter> | I really appreciate the transcription, but I'd love if we can now consider the transcription + another doc for short minutes with key points, even if they just capture resolution/conclusions |
| 19:53 | <shu> | with high quality transcription, AI summarization might actually be pretty good |
| 19:53 | <shu> | worth a try |
| 19:54 | <ljharb> | maybe wait til after manual editing |
| 19:54 | <shu> | yeah |
| 19:54 | <leobalter> | AI or human summaries work for me, as long as they capture key points such as resolutions for each topic. |
| 19:54 | <eemeli | FOSDEM> | Put this on TCQ as well, but also getting transcription for hybrid meetings would be great. |
| 19:55 | <ljharb> | i would expect it to apply to every meeting |
| 19:56 | <leobalter> | I'll have family visiting, so won't be able to join the plenary in person so soon. I miss going in person! |
| 19:56 | <ryzokuken> | yeah, the transcriptionist will be at every plenary meeting from here on out |
| 19:56 | <Michael Ficarra> | will they be remote at hybrid meetings? |
| 19:56 | <ryzokuken> | yeah |
| 19:56 | <ryzokuken> | atleast that is my understanding |
| 19:57 | <ryzokuken> | that said, I hope over time we can expand to the TG meetings as well (like the regularly scheduled TG2 and TG3 meetings) |
| 19:57 | <Michael Ficarra> | TG3 😢 |
| 19:59 | <littledan> | yeah, the transcriptionist will be at every plenary meeting from here on out |
| 20:00 | <littledan> | that said, I hope over time we can expand to the TG meetings as well (like the regularly scheduled TG2 and TG3 meetings) |
| 20:10 | <littledan> | For summaries: you don't have to be the proposal champion to write the summary; anyone can do it |
| 20:10 | <littledan> | I will write summaries for a couple more topics; it'd be great to split up the work among everyone who has the bandwidth for it |
| 20:13 | <rbuckton> | shu: regarding parameter decorators. There is a fairly robust ecosystem of TypeScript projects using legacy/experimental decorators that show that it is an extremely valuable feature, and not just with dependency injection. There are a number of capabilities it could enable:
Both Parameter Decorators and Metadata are critical to moving the rest of the TS community off of legacy decorators. I'm also hoping that Grouped Accessors will solve the last migration hurdle for entangling |
| 20:15 | <rbuckton> | IIRC, parameter decorators are also used in some ORM tools to indicate how an entity should be constructed when re-hydrating from a database. |
| 20:15 | <rbuckton> | I have a rough outline of what I'm think for parameter decorators here: https://github.com/tc39/proposal-decorators/issues/47#issuecomment-1397714899 I hope to have a proposal ready within the next two plenary sessions depending on my schedule. |
| 20:22 | <leobalter> | Rob Palmer danielrosenwasser rbuckton https://twitter.com/leobalter/status/1621242353494425602 |
| 20:25 | <littledan> | Rob Palmer danielrosenwasser rbuckton https://twitter.com/leobalter/status/1621242353494425602 |
| 20:26 | <leobalter> | I first posted a summary to my internal team, so posting on twitter had a delay :) |
| 21:34 | <shu> | rbuckton: thanks for the details |