2022-04-01 [06:39:44.0504] I should have some time to work on the updated transform in the next month or so [06:39:53.0735] I want to get the new metadata proposal up first [06:39:55.0073] * I want to get the new metadata proposal up first [06:40:07.0731] since it will likely be significantly simpler, based on feedback from the plenary [06:40:48.0739] ljharb: Can you setup the repo for the proposal? Or should I set it up and then transfer it? [06:40:58.0875] should probably be `proposal-decorator-metadata` [06:41:00.0129] * should probably be \`proposal-decorator-metadata` [06:41:05.0220] * should probably be `proposal-decorator-metadata` [08:35:40.0740] I can make it later today [09:24:31.0009] /me wonders if he can contribute more than just terrible ideas... [09:33:57.0535] ideas are always welcome :D though the proposal is unlikely to change significantly at this point [09:34:10.0155] there are potential follow on proposals however [09:34:16.0874] would definitely love help [09:35:07.0380] Well, this came to mind just a while ago on another channel: > Maybe we could've forgotten the prefix decorators alltogether and instead have class A { function b() {} |@> methodDecorator } |@> classDecorator, but I guess we're too late. [09:36:41.0911] yeah, I think that would be a significant divergence at this point [09:37:16.0291] the syntax has been agreed on for quite some time, much longer than the semantics, so I think it's very unlikely to change [09:37:36.0526] pzuraq: https://github.com/tc39/proposal-decorator-metadata ping me when it's somewhat fleshed out, and i'll add it to the proposals repo [09:37:46.0363] awesome, ty! [09:39:05.0515] > <@pzura:matrix.org> the syntax has been agreed on for quite some time, much longer than the semantics, so I think it's very unlikely to change I do understand that. I just wish I could've thought of that half a year earlier. [09:40:01.0536] I moreso mean the syntax has been agreed on for a few years at least at this point [09:40:08.0476] ish, it could have changed [09:40:14.0130] but that has not come up in discussions much [09:40:30.0188] and it would have probably taken a really really good argument to change it [09:40:48.0940] the best argument I can see for this alternative is it's kind of like pipes, but pipes aren't even a given at this point [09:51:41.0887] It's just something I wish had been brought up before. I don't think there's really any advantage for prefix over this form other than the fact that other languages use similar style. The infix operator style has the difference of clearer evaluation order at least. There's also different usage possibilities, which admittedly might not make sense under more scrutiny. :-) [09:52:04.0646] * It's just something I wish had been brought up before. I don't think there's really any advantage for prefix over this form other than the fact that other languages use similar style. The infix operator style has the difference of clearer evaluation order at least. There's also different usage possibilities, which admittedly might not make sense under more scrutiny. :-) [09:52:29.0609] yeah, that's fair [09:54:13.0271] I feel like either form could be more intuitive [09:54:17.0066] but I'm probably biased after working on it for so many years to be fair 😅 2022-04-04 [08:24:13.0570] ljharb: could you update the meeting invite for decorators to remove the discord server and add the link to this matrix room? https://matrix.to/#/#tc39-decorators:matrix.org [08:35:14.0703] Hay everyone, unfortunately I will not be able to be at the meeting tomorrow. I already chatted with Chris last week with some of my questions about designing metadata in out-of-class elements. [10:51:46.0682] > <@pzura:matrix.org> ljharb: could you update the meeting invite for decorators to remove the discord server and add the link to this matrix room? https://matrix.to/#/#tc39-decorators:matrix.org done [10:52:15.0589] ty [10:58:24.0250] lmk when the metadata repo is set up, so i can add it to the proposals list [13:08:31.0556] 👍️ planning on getting to that this week, wanted to gather feedback at tomorrow's meeting first, but should have it up by the weekend at the latest [13:09:10.0628] hmm, I think I'm going to need to make a new agenda/notes doc as well [13:09:42.0182] I cancelled my Google apps subscription and all the docs that were on it are gone [13:10:09.0210] (I have them in a backup, just not online) 2022-04-05 [06:17:58.0278] https://docs.google.com/document/d/1mY0YPejZWlYCuOaNiHRcUhf2BCHJ1qgmVFtVgu4K1ps/edit?usp=sharing [06:18:49.0209] ljharb: when you get a sec, can you update the meeting description to replace the existing agenda link with this one? 2022-04-06 [14:36:08.0278] In RS:ClassDefinitionEvaluation of https://arai-a.github.io/ecma262-compare/?pr=2417, we invoke `PrivateMethodOrAccessorAdd` on each element of staticPrivateMethod, but staticPrivateMethod is not defined in previous steps. I am wondering for a static private accessor: ``` class C { static accessor #p } ``` at which step is the private name `#p` registered to `C`.[[PrivateElements]]? I feel like it should be handled in `PrivateMethodOrAccessorAdd` just like getter/setter, and its BackingStorageKey will be registered in InitializeFieldOrAccessor separately. [14:39:19.0111] > <@jlhwung:matrix.org> In RS:ClassDefinitionEvaluation of https://arai-a.github.io/ecma262-compare/?pr=2417, we invoke `PrivateMethodOrAccessorAdd` on each element of staticPrivateMethod, but staticPrivateMethod is not defined in previous steps. > > I am wondering for a static private accessor: > > ``` > class C { static accessor #p } > ``` > > at which step is the private name `#p` registered to `C`.[[PrivateElements]]? I feel like it should be handled in `PrivateMethodOrAccessorAdd` just like getter/setter, and its BackingStorageKey will be registered in InitializeFieldOrAccessor separately. This can be observed from half-constructed class: ``` ``` [14:42:14.0226] > <@pzura:matrix.org> ljharb: when you get a sec, can you update the meeting description to replace the existing agenda link with this one? sorry for the delay; this should be done [14:44:29.0810] * This can be observed from a half-constructed class: ``` try { var halfConstructed; class C { static test() { #x in C; //true or false? } static accessor #x; static accessor #y = (() => { halfConstructed = C; throw new Error; })(); } } catch { halfConstructed.test() } ``` 2022-04-07 [19:34:31.0386] is there any in process work to split the metadata part to a separate proposal? [19:36:31.0446] * is there any in process work to split the metadata part to a separate proposal since the metadata part is left as stage 2? [05:17:44.0999] yes, I'm going to be working on getting that started this weekend [09:03:18.0531] > <@pzura:matrix.org> yes, I'm going to be working on getting that started this weekend That will be great. I'd be happy to volunteer to work on test262 :D [10:14:47.0841] that would be super helpful :D 2022-04-10 [12:32:05.0692] ljharb: ok, updated the proposal README! [12:32:24.0316] still need to polish it up a bit, add some examples, but it's a basic explainer for now 2022-04-11 [20:05:41.0877] pzuraq: i forgot to create it from the template (oops) so i just pushed up a commit that adds all those files