| 00:10 | <ljharb> | i really like andrew's two-physical-location suggestion |
| 00:12 | <michaelficarra> | do we need the remote plenaries at all if we just held these topic-oriented calls? |
| 00:12 | <ystartsev> | yes |
| 00:12 | <michaelficarra> | ystartsev: why? |
| 00:12 | <ystartsev> | they have different purposes |
| 00:12 | <ystartsev> | one is plenary, the other is feedback |
| 00:12 | <ystartsev> | plenary has decisions |
| 00:12 | <devsnek> | full plenary gets people who aren't focused on x looking at x |
| 00:13 | <michaelficarra> | am I wrong in understanding that the goal with the first part is that we just want to reduce in-person plenaries? |
| 00:14 | <ystartsev> | from my perspective the two tasks need different kinds of focus |
| 00:14 | <jridgewell> | I agree with ystartsev |
| 00:14 | <ystartsev> | feedback is generative, decision making is narrowing -- we say no to things |
| 00:14 | <michaelficarra> | okay so for those who support remote plenary, why do you support it? |
| 00:15 | <ystartsev> | right now im remote. it works well. the main problem i am facing is that its three days in a row; I also participate in other standards bodies who have a weekly plenary meeting for 1 hour and meet once a year. it works well there |
| 00:15 | <michaelficarra> | we can have fewer in-person meetings if we just move some of the feedback and review from those meetings to remote meetings (where non-binding decisions are made) |
| 00:15 | <ystartsev> | the travel burden of 6 times a year is very hard for someone not in the USA, and we lose a lot of participation as a result |
| 00:16 | <ystartsev> | feedback rounds have different forms of thinking. i don't think they directly translate into decisons |
| 00:16 | <ystartsev> | and if we use incubation things as decision making spaces, then the real benefit of feedback rounds is lessened. |
| 00:16 | <michaelficarra> | ystartsev: I am getting the feeling you think I'm supporting 6 in-person meetings |
| 00:17 | <ystartsev> | no, i hear you -- you are fine with reducing without making decisions in calls |
| 00:17 | <michaelficarra> | yes and I think we agree on that point |
| 00:17 | <ystartsev> | my preference is to make decisions in calls, because i don't see that much benefit to keeping it to in person plenaries |
| 00:17 | <ystartsev> | and, i think that the two different forms of thinking are important |
| 00:18 | <ystartsev> | i would not be completely opposed to what you are proposing, for what its worth |
| 00:18 | <michaelficarra> | okay so you think we should have fewer in-person meetings, remote plenaries, and incubation calls? |
| 00:18 | <ystartsev> | i suspect incubation calls will be a subset of the committee |
| 00:18 | <michaelficarra> | yes I think that's the idea |
| 00:18 | <ljharb> | i suspect you're right |
| 00:20 | <ljharb> | tbh i don't think incubation calls (which i think are a good thing) really impact the remote plenary discussion, except in that it adds to the number of frequent calls that delegates have to add to their calendar |
| 00:20 | <ystartsev> | ^yes thats true |
| 00:21 | <ljharb> | eg i already have about 6 hour-long calls, some weekly, some bi-weekly, and incubation calls and remote plenaries would add more things to that |
| 00:21 | <ljharb> | (probably more, i didn't go cout) |
| 00:21 | <ljharb> | *count |
| 00:28 | <decompil_> | as a concrete action, can we just get the incubation calls going? |
| 00:32 | <robpalme> | resuming at 14:42 with hax (10 mins) |
| 00:41 | <robpalme> | haxjs: please be aware that your timebox is reduced by 10 minutes due to your previous item overrunning. so you have 20mins from now. |
| 00:43 | <sffc> | akirose: interested in the panel |
| 00:44 | <shu> | decompiled: i didn't want to spring it on people without heads up i guess, but since it's designed as a subset anyway, we can do a "trial run" |
| 00:44 | <gibson042> | I strongly agree with ystartsev and others about the quality of less-frequent in-person plenaries improving from better overall presence and participation |
| 00:44 | <shu> | decompiled: a trial run before the next in-person meeting |
| 00:44 | <shu> | decompiled: look out for a reflector thread if interested! |
| 00:45 | <decompiled> | shu: will do. definitely interested longer term as I bring subsequent proposals. would have helped ahead of the Object iteration one this time π |
| 00:45 | <shu> | decompiled: one thing we didn't get a chance to hammer on some more is that dan and i believe the incubation calls should be good mentoring spaces |
| 00:45 | <shu> | less people, more relaxed, no stigma about questions and taking time |
| 00:46 | <shu> | well, there'll be timeboxes, but there shouldn't be pressure that the end of the timebox means we need to have a conclusion |
| 00:46 | <decompiled> | yup, definitely a good principle to follow -- will help make this committee more inclusive and welcoming for sure |
| 00:49 | <rickbutton> | +1 shu |
| 01:03 | <ljharb> | jridgewell: `apply` is already a MOP operation, no? |
| 01:03 | <jridgewell> | Oh, I thought it was call. |
| 01:04 | <ljharb> | aren't apply vs call the same? |
| 01:04 | <akirose> | something about array vs arg list? |
| 01:04 | <akirose> | i didn't even google that |
| 01:05 | <jridgewell> | There are currently two operations in `obj.foo()` |
| 01:05 | <jridgewell> | 1. A GET |
| 01:05 | <jridgewell> | 2. An APPLY |
| 01:06 | <jridgewell> | (I think that APPLY is badly named, but oh well) |
| 01:06 | <jridgewell> | If we could instead combine those into a single "apply" operation |
| 01:06 | <jridgewell> | Then we could easily use wrapping proxies on the object to detect improper use |
| 01:06 | <ljharb> | ah like a getApply or something |
| 01:06 | <jridgewell> | Yah |
| 01:06 | <jridgewell> | Mark has wanted one for a while |
| 01:06 | <ljharb> | but then a proxy could make `obj.foo()` do something different than `(0,obj.foo).call(obj)` |
| 01:06 | <ljharb> | that seems super weird |
| 01:07 | <jridgewell> | Yes |
| 01:09 | <jridgewell> | Agree with shu |
| 01:10 | <ystartsev> | also agree with shu |
| 01:10 | <devsnek> | is shu the one that said it shouldn't stage 1 if we know its not going to get past that |
| 01:11 | <jridgewell> | I think he doesn't want to confuse people |
| 01:11 | <jridgewell> | The current solutions presented are unlikely to advance |
| 01:11 | <devsnek> | no i'm just trying to track who said what |
| 01:11 | <jridgewell> | So saying they're stage 1 would be confusing |
| 01:11 | <jridgewell> | Yes |
| 01:11 | <devsnek> | cool |
| 01:11 | <jridgewell> | That was shu |
| 01:11 | <ljharb> | devsnek: imo shu said that if the stage 1 thing is called "X", but "X" isn't the thing that's likely to proceed, it shouldn't be called "X" |
| 01:12 | <devsnek> | ok yes i realize it was a bad summary |
| 01:12 | <ljharb> | and since stage 1 is supposed to be about solving a problem, stage 1 proposals should probably be consistently/thoroughly named in a way that describes the problem, not a particular solution |
| 01:16 | <wsdferdksl> | I'm very uncomfortable with the pressure to make stage 1 proposals very vague. |
| 01:16 | <ljharb> | wsdferdksl: not vague - specific about the problem, which is what stage 1 is about |
| 01:16 | <wsdferdksl> | That's vague. |
| 01:17 | <apaprocki> | it is only an issue in cases where the proposed solution has clear objections but the "idea" has merit |
| 01:17 | <wsdferdksl> | I can name lots of problems for which there will be as many opinions about what a solution could be as there are folks in the meeting |
| 01:17 | <apaprocki> | that doesn't mean concrete stage 1 proposals are bad |
| 01:17 | <ljharb> | wsdferdksl: sure, but debating the solution is a stage 2 concern |
| 01:17 | <apaprocki> | just that if the concrete idea has clear objections, it needs to become more general |
| 01:17 | <ljharb> | wsdferdksl: meaning, it's mostly irrelevant when discussing stage 1 advancement |
| 01:18 | <wsdferdksl> | Not being on the same page just wastes the committee's time |
| 01:18 | <ljharb> | that's why it's so important that we're all on the same page about what problem is being solved |
| 01:18 | <ljharb> | (before we debate solutions, for which the primary motivating problem should be informing us) |
| 01:19 | <devsnek> | they are not blocked |
| 01:19 | <wsdferdksl> | Debating problems is not productive without a solution in mind. It's a waste of time. |
| 01:19 | <devsnek> | they could easily put this data in the import maps |
| 01:19 | <devsnek> | or something similar |
| 01:19 | <devsnek> | would reduce duplication too |
| 01:19 | <ljharb> | wsdferdksl: that's a strong opinion i'm not sure is universally shared |
| 01:20 | <wsdferdksl> | It probably isn't, but it's become a problem at this meeting. |
| 01:20 | <ystartsev> | who is wsderdksl? |
| 01:20 | <ystartsev> | can you set your whois? |
| 01:21 | <akirose> | ++ waldemar please add your name to your nick |
| 01:21 | <ljharb> | wsdferdksl: i certainly expect most stage 1 proposals to have a solution in mind, but discussing that solution before we even agree that the problem needs solving imo is a much bigger waste of time |
| 01:21 | <wsdferdksl> | Sure |
| 01:21 | <ystartsev> | thanks |
| 01:22 | <wsdferdksl> | I was replying to ljharb |
| 01:22 | <ljharb> | wsdferdksl: i think that when a stage 1 proposal has a clearly understood problem, that it makes total sense to focus on a primary solution |
| 01:26 | <sffc> | akirose: I'd like at least 5-10 minutes to pitch my problem and get a list of people with opinions so we can follow up offline |
| 01:27 | <robpalme> | sffc: we might be able to get you 5 mins. modules finishes at 15:50. |
| 01:30 | <haxjs> | I'm a little confused about how a stage 1 proposal should be, I try my best to explain the problems, the use cases, and the possible solutions. It may be better to summary the question domain as: we need 1. a runtime reflection mechanism to check the intention of a callable whether it meet the requirement of an API, so it could protect programmers, 2. a declarative mechanism to mark the intention of a function |
| 01:30 | <haxjs> | whether it's a method (we already have the way for constructor and normal callback like arrow functions) . could such description better for advance for stage 1?? |
| 01:30 | <michaelficarra> | haxjs: if you want help rewording your thisArgumentExpected proposal to be acceptable for stage 1, let me know |
| 01:30 | <michaelficarra> | oh, looks like we crossed paths, let me explain |
| 01:31 | <michaelficarra> | so the way you've described the domain you're looking into here seems fine to me, we just need to update the proposal document to remove the specific solution you brought forward |
| 01:32 | <ljharb> | (or de-emphasize?) |
| 01:32 | <michaelficarra> | shu was afraid that people would read too much into the proposed solution and assume we were going that route, when we do not want to express that intention |
| 01:32 | <haxjs> | Oh. but it seems there are some doubt about proposals without concrete solutions as possible direction in the past?? |
| 01:32 | <michaelficarra> | haxjs: what are some examples of those? |
| 01:32 | <michaelficarra> | or do you mean that there was a doubt that there even could be a solution? |
| 01:34 | <ljharb> | i think that if the readme talks about the problem space, and then clearly and explicitly describes "here is one potential solution" but also explains that the committee had reservations about it, that it's fine |
| 01:35 | <michaelficarra> | we'd have to get confirmation from shu on that |
| 01:35 | <haxjs> | ok. I will edit the readmes! |
| 01:35 | <shu> | i think given the magnitude of the feedback |
| 01:35 | <shu> | it's not a potential solution, but a proposed rejected solution |
| 01:35 | <michaelficarra> | haxjs: to be clear, the explicit this proposal was rejected from stage 1, regardless of readme changes |
| 01:36 | <michaelficarra> | shu: that is probably a better way to describe it, yeah |
| 01:36 | <shu> | or rather, a rejected proposed solution |
| 01:36 | <haxjs> | Ok. but i need to understand the main concerns about the reason of rejection. Currently I'm not sure I get them. |
| 01:36 | <shu> | (proposed rejected sounds like it was proposed to be rejected) |
| 01:37 | <michaelficarra> | haxjs: from Waldemar, "WH: This does not solve any problem and introduces a new way of saying `this` in the language, which is not a problem that we have. It is not that phrasing it in a different way would make it more acceptable, I donβt see this as solving a problem." |
| 01:38 | <michaelficarra> | I think the general feeling I got among delegates was that they could already alias in the body with a let declaration |
| 01:38 | <ljharb> | * const :-p |
| 01:38 | <michaelficarra> | whatever |
| 01:38 | <devsnek> | but if you use out of band you don't need to worry about a host supporting or rejecting your syntax |
| 01:39 | <devsnek> | cuz the host just loads the metadata it knows how to load |
| 01:39 | <haxjs> | why it could be? it just like normal parameters... don't understand this part. |
| 01:39 | <haxjs> | this parameter syntax is only for userland code, why it will affect host? |
| 01:40 | <ljharb> | haxjs: that comment was re module attributes |
| 01:40 | <haxjs> | oh sorry |
| 01:40 | <devsnek> | oh yeah i wasn't referring to your proposal hax sorry |
| 01:42 | <haxjs> | michaelficarra "I think the general feeling I got among delegates was that they could already alias in the body with a let declaration" --- naming it only the side effect of "this parameter syntax", I already listed many other important usages like annotation/decorator which never possible without syntax. |
| 01:42 | <devsnek> | Bakkot: was it you who said the host could just reject resolution |
| 01:42 | <devsnek> | if the as thing is present |
| 01:42 | <Bakkot> | that was keith_miller I think |
| 01:42 | <devsnek> | keith_miller: forgot to ping you above |
| 01:42 | <keith_miller> | Bakkot: What was me? |
| 01:43 | <Bakkot> | keith_miller "who said the host could just reject resolution" |
| 01:43 | <keith_miller> | I don't know where I'm looking |
| 01:43 | <Bakkot> | "if the as thing is present" |
| 01:43 | <devsnek> | if one host rejects the load and another host needs it |
| 01:43 | <keith_miller> | Oh, yeah |
| 01:43 | <keith_miller> | That was me |
| 01:43 | <devsnek> | your code can't be loaded by anything |
| 01:44 | <devsnek> | on the other hand if the web knows to load a manifest file |
| 01:44 | <keith_miller> | Uhh, I guess you need to know what host your running on |
| 01:44 | <devsnek> | well yeah |
| 01:44 | <devsnek> | but that's kind of unfortunate |
| 01:44 | <keith_miller> | I'm not saying it's a good practice |
| 01:44 | <devsnek> | i'm not sure there is a possible practice |
| 01:45 | <devsnek> | you support host a or host b |
| 01:49 | <MylesBorins> | thanks for the great feedback everyone |
| 01:49 | <michaelficarra> | bradleymeck hit the nail on the head here |
| 01:50 | <ljharb> | my question is similar, i think |
| 01:50 | <michaelficarra> | symbols if they implement multiple interfaces, strings otherwise |
| 01:50 | <rbuckton> | The problem is that its too early to know, these objects may have a dual purpose in the future. |
| 01:50 | <ljharb> | seems like making one thing have two purposes is problematic? |
| 01:51 | <michaelficarra> | if they're very clearly single-purpose, they're basically like an arguments bag: use strings |
| 01:51 | <michaelficarra> | otherwise, use symbols |
| 01:53 | <Bakkot> | two specific purposes would also be fine |
| 01:53 | <Bakkot> | the question is whether it's random other stuff, or just those things |
| 01:53 | <michaelficarra> | agreed Bakkot |
| 01:53 | <ljharb> | fair |
| 01:55 | <Bakkot> | e.g. iterator needed to be a protocol because you have all kinds of things which are iterable, .then needed to be a protocol because you have a kinds of things which can be in a promise, etc. but options bags should be string-based. |
| 01:56 | <Bakkot> | *_iterable_ needed to be a protocol. but iterator didn't. |
| 01:56 | <michaelficarra> | we should document this design philosophy somewhere |
| 01:56 | <michaelficarra> | it's important and the community should also be aware |
| 01:57 | <michaelficarra> | oh wait, I know! |
| 01:57 | <michaelficarra> | https://freenode.logbot.info/tc39-delegates/20200207#c3203202-c3203222 |
| 01:57 | <michaelficarra> | there we go, documented |
| 01:57 | <devsnek> | "Strings." is the motto of this month's tc39 |
| 01:57 | <devsnek> | oops wrong channel |
| 02:02 | <devsnek> | thanks everyone, see y'all next time! |
| 02:04 | <michaelficarra> | π devsnek |