| 00:01 | <rbuckton> | I've considered using an infix ~ as an indicator for partial application, i.e. obj.method~(a, ?), so obj~[key] might be reasonable. Thin-arrow is possible as well (i.e., obj->[key]), though that sequence of tokens get's into "obj.get is easier to write" territory |
| 00:07 | <rbuckton> | * % may be out as well. We'd considered it for the topic variable in pipeline, but IIRC % is hard to type on a number of international keyboard layouts. |
| 00:08 | <Kris Kowal> | We at Agoric are also hoping to use remote~.method() for async method invocation on a promise/placeholder for a remote object, remoteFunction~() for async function application, and promise~.propertyName for async get. |
| 00:09 | <Kris Kowal> | (On the mnemonic that ~ resembles a stream and each of these would be used to stream operations to remote objects.) |
| 00:10 | <rbuckton> | If f~() gets used for that, then I don't think there's any syntax that would ever work for partial application. |
| 00:11 | <rbuckton> | If you usedf~.() it would be consistent with f?.() at least, though I imagine f~.~() would end up being a bridge too far. |
| 00:13 | <rbuckton> | I still hold out hope for partial application, which is why I haven't withdrawn it, but where I left it one of the things it needed was a prefix token for the argument list. For a number of reasons I've discussed on the issue tracker, the token can't come before the method/function name since it has the wrong precedence for binding, and for partial application to be practically useful it can't have an arduous syntax. |
| 00:14 | <rbuckton> | One of the things that the original f(?) syntax for partial app lacked was the ability to indicate a partial 0-arity invocation, i.e. obj.method() isn't partial, and there's no way to defer its invocation, while object.method~() allows for 0-arity partial application. |
| 00:16 | <rbuckton> | The other upshot of using ~. for async invocation, is that you're not limited to ~ as there are a number of other symbols that are currently illegal before . in that position. |
| 00:21 | <rbuckton> | This is also why I'm not a fan of using up our syntax budget on a[@x] when we primarily want to support a narrow case for a small set of objects (Slice, Index, maybe WeakMap or a set of user-defined objects like Pick, etc.) that could easily be accomplished with a[x]. |
| 00:23 | <rbuckton> | Whatever we used for that would impact what's available for future proposals. i.e., any symbol in the place of @ in a[@x] means that symbol can never be used in a prefix position of an AssignmentExpression. A symbol before [ doesn't have that issue, but we have an even smaller number of symbols we can legally put before [ and still have it be somewhat ergonomic to type. |
| 00:27 | <rbuckton> | I'd love to be able to hook a[x] for numeric indexes, since that also gives us a way to make things like Array and TypedArray into regular objects instead of exotic objects. It also opens the door for user-defined numeric-indexed collection classes that work like Array, which can only be implemented via a Proxy today. |
| 04:23 | <Jack Works> | And that doesn't seem like a valuable use of our syntactic budget if we could merge them into just a[x], now all a[x] require 2 Get call instead of 1, that will be a huge performance cliff |
| 04:28 | <Jack Works> | Another problem, if there will be index/range I will really hope they are new primitive types. But it seems very impossible as current status. |
| 11:52 | <hax (HE Shi-Jun)> | We at Agoric are also hoping to use promise::Eventual:method() and promise::Eventual:propertyName. I think the old eventual send proposal do not have remoteFunction() feature, is it ok to use remoteFunction::Eventual:call() for that? (note, I plan to change :: and : delimiters, but I assume it should not the big issue for this case) |
| 16:54 | <snek> | i feel like some things should remain as DSLs |
| 17:06 | <Michael Ficarra> | or, in a versatile enough language, just libraries |
| 18:12 | <rbuckton> | I agree with Chris. It's much harder to validate tests without also writing an implementation. I'm wondering if it makes more sense to split the "implementation" part into two parts: the development/validation of the feature internally or flagged, and shipping the implementation unflagged. |
| 18:12 | <rbuckton> | Or I think I agree. I agree with the topic text at least, heh. |
| 18:17 | <littledan> | I like the names |
| 18:18 | <littledan> | (but keeping the numbers too sgtm) |
| 18:19 | <ljharb> | i def like re-adding names. but numbers should remain the primary thing |
| 18:19 | <littledan> | the reason for adding names is because they help explain what we're talking about. The new names are much much better than the old names, hence the change vs previously |
| 18:19 | <littledan> | (I have no opinion on what should be "primary"; maybe we should just start with not changing) |
| 18:20 | <ljharb> | well, i just mean, the numbers should never be absent from our communication about the stages; i don't care if the names are present also or not in every such communication |
| 18:20 | <rbuckton> | Stages: 1, 2, 2-3 transitional validation, 3, 4 |
| 18:20 | <ljharb> | (we also don't need to renumber; there's infinite numbers between 2 and 3) |
| 18:20 | <littledan> | I hope we can avoid this bike shedding debate blocking us from making the more meaningful process change that Michael proposed |
| 18:21 | <rbuckton> | Stage numbers don't need to be integral or floating-point |
| 18:21 | <ljharb> | your optimism is refreshing |
| 18:21 | <ljharb> | +<3 for whimsy |
| 18:21 | <Michael Ficarra> | I am anti-whimsy |
| 18:22 | <Chris de Almeida> | introducing the new stage with
|
| 18:22 | <littledan> | I prefer 2 3/4 or 2.75 because it expresses that it's closer to 3 |
| 18:22 | <ptomato> | whimsy is great for audiences in the know, usually falls flat and ends up being a barrier in external communication |
| 18:22 | <Rob Palmer> | I really like having the "External Communication" definition in the document, even if we don't use them as names or vocally. It's the best way of concisely explaining things to a wide audience. |
| 18:24 | <littledan> | Moving from Stage e to 3 should require consensus on the question of whether the tests are sufficiently done; it'd be sort of inappropriate to reject Stage 3 because you didn't like the design in the first place |
| 18:25 | <littledan> | oh sure if there's implementation experience at that point, requiring changes, then that'd be a good reason to hold back Stage 3 |
| 18:30 | <eemeli> | One way to keep the integer numbers would be to shift the lower end down, so random ideas are at stage -1, they're first accepted at stage 0, need spec text for stage 1, and this new stage would be stage 2. |
| 18:31 | <ljharb> | that'll cause a lot of confusion for existing data all over the internet |
| 18:31 | <eemeli> | But less than shifting the other end up a step. |
| 18:32 | <ljharb> | i think that any such disruption isn't worth keeping integers, personally |
| 18:34 | <snek> | i feel like we have several questions happening at once here |
| 18:34 | <snek> | the first is "what stages do we want to have" |
| 18:34 | <snek> | and only once we answer that can we talk about how to label them |
| 18:35 | <ljharb> | it seems like the stages as described are already what we want, we're just confirming the wording |
| 18:35 | <rbuckton> | imo, a clean break switching away from numbers to names is far preferrable to shifting stage numbers around. |
| 18:36 | <ljharb> | and a clean break is problematic for reasons i've described, so picking a noninteger number is what's left |
| 18:37 | <ljharb> | Chris de Almeida: numbers and names landed together with the post-ES6 process iirc, and i think we moved away from the names a few years back because nobody, internally or externally, was using them anyways |
| 18:39 | <Chris de Almeida> | yes, thanks for the correction -- I misremembered partially; trying to dig up the reasoning, but there was i18n aspect IIRC |
| 18:39 | <Chris de Almeida> | 10,20,30, with 10.20, 30.20, etc. is no different thatn 1,1.2,3.2, etc |
| 18:40 | <Chris de Almeida> | but I guess they have things like .93 in there |
| 18:40 | <rbuckton> | Again, we don't need to use integral or real numbers at all. The new stage could just be something like 2-3-validation or something, or rename stages like:0, 1, 2.approved, 2.validated, 3, 4 |
| 18:40 | <rbuckton> | Stages 2.a, 2.v (or 2.b) |
| 18:41 | <rbuckton> | since a/b/v/etc. don't imply a closeness or distance from 2 or 3 |
| 18:42 | <rbuckton> | Or just do stages 0, 1, 2, 2+tests, 3, 4, or something. |
| 18:42 | <rbuckton> | or "pre-3" |
| 18:42 | <Rob Palmer> | I guess the whole question of "can we migrate community understanding" was answered once by turning ESx -> ESxxxx digits eight years ago. I'd estimate that took two years to achieve widespread understanding. So Stage x -> Stage xx would probably be accepted in a similar timeframe. |
| 18:43 | <rbuckton> | Actually, "pre-3" doesn't seem too bad to me? |
| 18:43 | <ljharb> | having "3" in it seems very bad to me, as we discussed last plenary |
| 18:44 | <ljharb> | if it has "3" in it people will treat it as safe to use |
| 18:44 | <rbuckton> | Except it's "pre-", its even semver-ish. |
| 18:44 | <ljharb> | that took longer than 2 years, and also was because we were making yearly editions which was a huge change. and, people still refer to things by edition number (eslint still supports edition numbers in its config for ecmaVersion, even) |
| 18:45 | <rbuckton> | stage "almost-3-but-do-not-use-or-you-will-be-fired" /s |
| 18:45 | <ljharb> | Except it's "pre-", its even semver-ish. |
| 18:45 | <Chris de Almeida> | https://github.com/tc39/notes/blob/df1449925841bc77574e8e127611234670275575/meetings/2021-07/july-14.md#renaming-strawperson-to-concept-or-something-better |
| 18:46 | <Chris de Almeida> | this is the discussion that led to the removal of stage names |
| 18:46 | <rbuckton> | This new stage has the same entrance criteria that 3 did, so "pre-3" makes sense to me. "post-2" feels a bit odd to me, though. |
| 18:46 | <Chris de Almeida> | notably, the discussion actually began with trying to name a stage -- and that led to removal of the names entirely |
| 18:49 | <ljharb> | 0,1,2,name,3,4 works too, it'll just inevitably become referred to as "2.5" or similar, and then that's what it'll be called. if we don't pick a number, a number will be picked for us. |
| 18:49 | <rbuckton> | unproposed (old 0), exploring (old 1), draft (old 2), validation (new), candidate (old 3), adopted |
| 18:50 | <Rob Palmer> | Stage 2e1 |
| 18:50 | <Rob Palmer> | (that's a literal number) |
| 18:50 | <Chris de Almeida> | didn't we talk about e last time? |
| 18:51 | <nicolo-ribaudo> | 0,1,2,name,3,4 works too, it'll just inevitably become referred to as "2.5" or similar, and then that's what it'll be called. if we don't pick a number, a number will be picked for us. |
| 18:51 | <bakkot> | I don't know that people will pay enough attention for that to actually come up |
| 18:52 | <bakkot> | like if it's "2" and "test development" and "3", not a lot of people are going to get that excited about moving to phase "test development", even though it is in reality a big milestone |
| 18:52 | <ljharb> | there are a lot of podcasters and blog posters and twitter tech influencers that pay attention to stage progression (whether it's actually valuable for them to care or not) |
| 18:52 | <bakkot> | I guess I don't care that much about what name those people use |
| 18:53 | <ljharb> | we could also do 2.9 so that "just before 3" is strongly implied, and then there's no confusion with "e" |
| 18:53 | <Rob Palmer> | 2.testing (why not both?) |
| 18:54 | <Michael Ficarra> | I love the bingo call-out lol |
| 18:54 | <ryzokuken 🇮🇹> | 2-bis |
| 18:54 | <bakkot> | "2" and "2v" sgtm |
| 18:54 | <eemeli> | 2+ |
| 18:55 | <ljharb> | Christian Ulbrich: in new tcq can you make sure there's a way to rewind, so previous/accidentally advanced queue items aren't lost? :-) |
| 18:57 | <rbuckton> | What we want is to move the testing portion into stage 2, but allow the champion to have consensus on the specification text without rehashing old discussions when getting approval for tests. 2a/2b makes sense for me since as far as the community is concerned, they both still imply 2 |
| 18:57 | <ljharb> | msaboff: you think users can handle renumbering existing stages, but not a non-integer number? |
| 18:58 | <ljharb> | What we want is to move the testing portion into stage 2, but allow the champion to have consensus on the specification text without rehashing old discussions when getting approval for tests. 2a/2b makes sense for me since as far as the community is concerned, they both still imply 2 |
| 18:58 | <rbuckton> | TCQ really just needs polling instead of abusing temperature checks |
| 18:58 | <rbuckton> | the difference is that design can change radically in stage 2, but can NOT change radically in the new stage |
| 18:59 | <nicolo-ribaudo> | 2 hours free today to talk about consensus :) |
| 18:59 | <ljharb> | Yes, but if test acceptance is mostly pro-forma, a proposal shouldn't be in 2b for very long. |
| 18:59 | <ljharb> | but certainly most proposals shouldn't stay in the new stage very long. some will tho. |
| 18:59 | <bakkot> | TCQ really just needs polling instead of abusing temperature checks |
| 19:01 | <Michael Ficarra> | nicolo-ribaudo: you are right, and we don't even need avote: the chairs can just dictate this |
| 19:01 | <ljharb> | ehhh i think things that involve external communication outside the committee do require consensus |
| 19:02 | <rbuckton> | In general, I'd be fine with just needing tests to advance to Stage 3, if that's the crux of what we want, but I'm uncomfortable with demoting proposals that advanced prior to this change. |
| 19:03 | <ljharb> | it's important to have a step between "design is mostly final" and "tests are required", that's the whole point of this effort |
| 19:03 | <rbuckton> | Informally, a champion could get consensus on the specification text without advancement, write the tests at the end, then ask for advancement in the following meeting. |
| 19:04 | <rbuckton> | Or ask for conditional advancement pending the addition of tests, with a (mostly) pro-forma ratification of advancement when tests are complete. |
| 19:06 | <Michael Ficarra> | yeah ordinary members vote at GA, all members vote at TCs |
| 19:06 | <bakkot> |
|
| 19:07 | <bakkot> | per https://ecma-international.org/policies/rules/ |
| 19:07 | <Michael Ficarra> | Istvan clarifies in Meet that it would be 50% majority though |
| 19:07 | <ryzokuken 🇮🇹> | yeah it's per member and simple majority |
| 19:08 | <bakkot> | fwiw I would be fine with literally any process by which we can reach a decision, even if the decision reached is one I don't like |
| 19:08 | <rbuckton> | If we added polling, we could just indicate it is non-binding. What I was suggesting was just a better way to do what we've been abusing temp checks for. it's still essentially a temperature check |
| 19:08 | <ljharb> | RCV would be nice too :-) |
| 19:09 | <bakkot> | RCV is dangerously broken, approval all the way |
| 19:09 | <ljharb> | O.o i'd love to hear more about that; RCV seems like the best approach to me by a large margin for any voting (like, hear about it in general, not just as it applies to tc39) |
| 19:11 | <littledan> | yes I prefer to go with a temperature check |
| 19:11 | <nicolo-ribaudo> | Temp check on whether to do a temp check? |
| 19:11 | <snek> | i've never heard a strong argument against RCV so i am also interested |
| 19:12 | <rbuckton> | my reply was skipped? |
| 19:12 | <littledan> | I don't think there are any Ecma rules about how we do a temperature check, right? |
| 19:14 | <littledan> | +1 to rbuckton 's point |
| 19:14 | <littledan> | the temperature check was designed this way deliberately, because some people were extremely opposed to non-binding polling. It sounds like that opposition has fallen away |
| 19:16 | <Michael Ficarra> | reminder that we only have 15min left |
| 19:16 | <waldemar> | Temperature check scale is asymmetric, so it matters how whatever the question is, is phrased. |
| 19:16 | <rbuckton> | "Temperature Check" is designed to ask the committee's impression about a single topic. i.e., if we were to do this via temperature check, it would be a series of questions:
Saying "smiley means E" is just an abuse of the temperature check to do polling. |
| 19:17 | <nicolo-ribaudo> |
|
| 19:17 | <rbuckton> | If we're going to have polling/voting/etc., it makes sense to add that to TCQ |
| 19:18 | <rbuckton> | Yeah true, I want to be able to say what I do not like other than what I like |
| 19:18 | <snek> | i guess some people like STAR |
| 19:18 | <ptomato> | we've used what is basically non-binding RCV in Temporal champions meetings as a way to get a quick picture of the position of the group |
| 19:19 | <Michael Ficarra> | I think temp check on what we don't like would be useful |
| 19:19 | <littledan> | +1 to "general consensus" (definition tbd) |
| 19:19 | <littledan> | this is the typical Ecma/standard best practice |
| 19:23 | <bakkot> | oh jeeze this is a large topic but the big obvious one is that it fails monotonicity, which means you can make someone lose by ranking them higher |
| 19:25 | <littledan> | wait what are we voting on? |
| 19:25 | <bakkot> | https://electionscience.org/voting-methods/runoff-election-the-limits-of-ranked-choice-voting/ |
| 19:25 | <rbuckton> | E |
| 19:25 | <rbuckton> | 2.e? |
| 19:26 | <rbuckton> | I thought it was just E |
| 19:26 | <ljharb> | lowercase e, yes |
| 19:26 | <ljharb> | like the math constant, 2.718 whatever |
| 19:26 | <rbuckton> | Then we need an option 2.a/2.b |
| 19:26 | <rbuckton> | Because that is none of the three options |
| 19:26 | <ljharb> | Rob Palmer ryzokuken 🇮🇹 : ^ for option 4 |
| 19:28 | <ljharb> | ^ that is for Option 1, Stage e |
| 19:30 | <ljharb> | ^ that is for Option 2, Stage 2.x (ie, 2.5, 2.7, 2.9, etc) |
| 19:30 | <ljharb> | ^ that is for Option 3, Stage 10/20/25/30/40 |
| 19:31 | <rbuckton> | FYI, I do have a 5th option as a topic in the queue that we haven't discussed yet |
| 19:31 | <ljharb> | we already have consensus from last plenary of making a new stage, so i assume that suggestion wouldn't do well |
| 19:31 | <nicolo-ribaudo> | That's not really related to the naming poll, it's about something we already discussed (whether we want a new stage or not) |
| 19:32 | <ljharb> | ^ that is for Option 4, Stage 2.a/2.b |
| 19:32 | <rbuckton> | Yes, but I don't believe we specifically discussed this option in prior discussions. |
| 19:32 | <Chris de Almeida> | option 2 clear winner |
| 19:33 | <ljharb> | now do we vote on which digit goes after the decimal place? |
| 19:33 | <Michael Ficarra> | 😠Jordan no |
| 19:33 | <Chris de Almeida> | lol |
| 19:33 | <nicolo-ribaudo> | now do we vote on which digit goes after the decimal place? |
| 19:34 | <Michael Ficarra> | everyone post a number and we'll take the average |
| 19:34 | <ptomato> | average rounded to 1 decimal place! |
| 19:34 | <Michael Ficarra> | .toFixed(1) |
| 19:35 | <bakkot> | also it doesn't actually prevent third-party spoilers except when the third party is very unpopular. which is especially dumb because "ending the entrenched two-party system" the whole reason most people like RCV https://electionscience.org/library/the-spoiler-effect/ |
| 19:35 | <Chris de Almeida> | 2.6Ì…6Ì…6Ì… |
| 19:35 | <eemeli> | littledan: Missing 2.718. :) |
| 19:36 | <Jesse> | chris you need only one 6 and a bar |
| 19:36 | <ljharb> | aww, i can't vote for more than one? |
| 19:36 | <snek> | if we take every number between 2 and 3 and put them in a big table, and then add up each subsequent decimal place, we will have a new number which does not appear in the table and that will be our phase number |
| 19:36 | <Chris de Almeida> | chris you need only one 6 and a bar |
| 19:36 | <rbuckton> | This is why I liked 2.b, it didn't need a numeric representation |
| 19:36 | <ljharb> | b is 2 |
| 19:37 | <ljharb> | it just requires renaming 2 to "2, but part 1", ie, 2.a |
| 19:37 | <ethanarrowood> | I need a 9 and 3/4 option please /s |
| 19:37 | <rbuckton> | Are all delegates in attendance in matrix as well? |
| 19:37 | <ljharb> | is there a better system than RCV you'd suggest? |
| 19:38 | <bakkot> | approval |
| 19:38 | <dminor> | Go with 2 and 3/4 :) |
| 19:38 | <rbuckton> | Otherwise the poll above isn't useful since it excludes folks not in the chat |
| 19:38 | <bakkot> | I would also accept STAR or range |
| 19:38 | <Richard Gibson> | https://en.wikipedia.org/wiki/Condorcet_method in general, approval as a practical special case |
| 19:38 | <ljharb> | what is "approval"? |
| 19:38 | <nicolo-ribaudo> | I don't think matrix polls count but heh I would also be ok with just reading the answer in a cup or tea or in the lines on my hand at this point |
| 19:38 | <bakkot> | vote for as many candidates as you like, candidate with the most votes wins |
| 19:39 | <bakkot> | don't even have to issue new ballots |
| 19:39 | <rbuckton> | If test acceptance is mostly pro-forma, 2.5 seems like the wrong answer since that stage is not halfway between 2 and 3 |
| 19:43 | <msaboff> | I don't see how a stage number with more significant digits than the other stage numbers should convey something besides being in that stage. |
| 19:43 | <Michael Ficarra> | haha good luck making that process change eemeli |
| 19:44 | <Chris de Almeida> | can't we split the diff with 2.7 ? |
| 19:44 | <rbuckton> | I don't see how a stage number with more significant digits than the other stage numbers should convey something besides being in that stage. |
| 19:44 | <Chris de Almeida> | sorry not sorry |
| 19:45 | <msaboff> | It is a separate stage. |
| 19:46 | <rbuckton> | That doesn't change the implication of 2.5. That's why I suggested 2.b as it has absolutely no bearing on the distance between 2 and 3 |
| 19:46 | <ljharb> | ^ this is for Option A, 2.5 |
| 19:47 | <nicolo-ribaudo> | One benefit of 2.7 over 2.9 is that if needed there is space between 2.7 and 3 without one day having also 2.95 |
| 19:47 | <ljharb> | 2.10 |
| 19:47 | <nicolo-ribaudo> | Love it |
| 19:47 | <Jesse> | blasphemy |
| 19:47 | <nicolo-ribaudo> | Nobody ever said that we use base 10 anyway |
| 19:47 | <rbuckton> | One benefit of 2.7 over 2.9 is that if needed there is space between 2.7 and 3 without one day having also 2.95 |
| 19:47 | <littledan> | that would be 2.a |
| 19:47 | <littledan> | we're coming full circle |
| 19:47 | <ljharb> | ^ this is for Option B, 2.9 |
| 19:48 | <rbuckton> | No, that would be 3.14159 |
| 19:48 | <Chris de Almeida> | spoiler alert: 2.7 wins |
| 19:49 | <ljharb> | ^ this is for Option C, 2.7 |
| 19:49 | <Chris de Almeida> | and the crowd goes mild |
| 19:50 | <Michael Ficarra> | yay, now we can all be unhappy! |
| 19:50 | <snek> | i was already unhappy |
| 19:50 | <nicolo-ribaudo> | Can we merge the PR with numbers and talk about names next time? |
| 19:50 | <nicolo-ribaudo> | I'm tired |
| 19:50 | <bakkot> | yes please we can just not name things |
| 19:51 | <dminor> | I hope we can avoid naming the stages |
| 19:51 | <Chris de Almeida> | yes, I thought this meant we don't have to name |
| 19:52 | <Jesse> | TC39 Anonymous |
| 19:52 | <Chris de Almeida> | or at the very least, unblocks the stage itself / process change |
| 19:52 | <dminor> | I think Ron's point that the names can be misleading or overly simplified is a good reason to not try to choose a single name. |
| 19:52 | <nicolo-ribaudo> | (I like re-introducing names) |
| 19:55 | <rbuckton> | msaboff: Not a fan of 2.7 either, but a subjective implication of moving from integral stage numbers to real stage numbers is that the value after the dot is interpreted as a fractional value. 2.b would have avoided that implication. Following your logic, 2.5 doesn't make sense as a stage name either. |
| 19:57 | <Chris de Almeida> | to be clear, I don't oppose regressing decorator metadata to 2.7; it just needs to be on the agenda |
| 19:58 | <bakkot> | notes are a little bad this section; I suspect I was not the only note taker who was having difficulty with actively following along this topic |
| 19:58 | <Chris de Almeida> | to be fair, it was a wild ride |
| 20:00 | <ethanarrowood> | Can someone clarify a part of the process for me? When I had to come off mute to get clarification for the voting we were doing, should I have instead use tcq "Clarifying Question" button? Is TCQ the like main controller for who speaks when? Is it sorta like raising your hand on a zoom meeting where it sticks you in a queue? |
| 20:00 | <Chris de Almeida> | probably 'point of order' on that one actually |
| 20:00 | <ethanarrowood> | (and apologies again if this is common knowledge. this is my first plenary so I'm learning a ton about the actual process of everything) |
| 20:01 | <Chris de Almeida> | ethanarrowood: |
| 20:01 | <Chris de Almeida> | https://github.com/tc39/how-we-work/blob/main/how-to-participate-in-meetings.md |
| 20:01 | <Chris de Almeida> | the guidance there should help; there's a section on what the options mean |
| 20:02 | <ethanarrowood> | excellent thank you! |
| 20:05 | <Chris de Almeida> | we picked the least disliked option.. so that's gotta be good for something |
| 20:05 | <Chris de Almeida> | in any case, big thanks to Michael Ficarra for proposing and landing this. 📈 |
| 20:37 | <snek> | does anyone have access to apple's secret internal workings and would be able to tell me whether there is a radar bug tracking dns prefetch with csp default-src? |
| 21:02 | <msaboff> | snek: Do you have more details to help me search? |
| 21:03 | <snek> | snek: Do you have more details to help me search? prefetch-src may also be a good search term |
| 21:03 | <snek> | also this https://w3c.github.io/webappsec-csp/#does-resource-hint-violate-policy |
| 21:05 | <ryzokuken 🇮🇹> | https://yourcalendricalfallacyis.com/ |
| 21:06 | <ljharb> | ok, from what i've read so far, i'm convinced, thanks |
| 21:14 | <msaboff> | |
| 21:15 | <snek> | I found a radar that points to this bugzilla bug. |
| 21:15 | <snek> | so i'm wondering where webkit is on getting to that reality |
| 21:18 | <ljharb> | it's way too late to change temporal's design in this way, but the more i hear these presentations the more i think it should all have thrown by default |
| 21:20 | <bakkot> | generally I am going to defer to the datetime people about appropriate defaults for datetime things |
| 21:20 | <ljharb> | i would agree, which is why we're here :-) but if a day or time doesn't exist, that's a bug, and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. |
| 21:21 | <ljharb> | iow "stop coercing things" doesn't feel philosophically aligned with "silently change input values by default" to me |
| 21:21 | <littledan> | also think about Adar 2! |
| 21:22 | <ljharb> | indeed, i could be a whole month off without knowing it |
| 21:22 | <bakkot> | i would agree, which is why we're here :-) but if a day or time doesn't exist, that's a bug, and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. |
| 21:22 | <ljharb> | that's always going to be the case tho, when users enter something outside the data model |
| 21:22 | <bakkot> | "stop coercing things" refers to types, which is to say bugs that you will hit instantly unless you're mixing types (which is on you) |
| 21:23 | <ljharb> | so since you always have to have some kind of "hey user, this is wrong, double check", why wouldn't you do the same here? |
| 21:23 | <bakkot> | you're not always at the point where user data is being entered |
| 21:23 | <bakkot> | like they ask for something to happen at 2:30AM every day |
| 21:23 | <bakkot> | that's fine |
| 21:23 | <ljharb> | sure. the semantics vary, and in that case clamping is fine |
| 21:23 | <bakkot> | and then Mar 12 comes along, and your program needs to run |
| 21:23 | <bakkot> | erroring in that case is bad |
| 21:24 | <bakkot> | that seems like the thing guiding this design, and that seems good to me |
| 21:24 | <ljharb> | but since in nonzero cases it's not fine, the default should probably have been to error. and then me, the author of this cron program, can pass the option to clamp |
| 21:24 | <bakkot> | you would not have been exposed to the error until 3am on March 12 |
| 21:24 | <littledan> | I think the normal semantics would be, if I'm in Adar 2 and I am supposed to identify "today a year from now", it would go to Adar 1 if next year isn't a leap year |
| 21:24 | <ljharb> | exceptions in production are much easier to find and fix ime than silent bugs, but ymmv i suppose |
| 21:24 | <bakkot> | which is much too late |
| 21:26 | <bakkot> | exceptions in production are much easier to find and fix ime than silent bugs, but ymmv i suppose |
| 21:26 | <bakkot> | there is a sensible answer to that question and the default should be to return the sensible answer to that question |
| 21:26 | <ljharb> | it depends on the use case. in some it isn't. in some it is. |
| 21:26 | <ljharb> | so there isn't a universal sensible answer, and in those scenarios i prefer to throw and let the user explicitly disambiguate. |
| 21:27 | <bakkot> | there is a 99% answer; it is better to default to that, and then if you want something else to opt in to that. |
| 21:27 | <ljharb> | i'd love some citations for "99%" |
| 21:27 | <bakkot> | this is not good always but seems clearly good here |
| 21:28 | <bakkot> | i'd love some citations for "99%" |
| 21:28 | <ljharb> | sure. it just doesn't match my experience. nor my intuition overall. |
| 21:29 | <bakkot> | so there isn't a universal sensible answer, and in those scenarios i prefer to throw and let the user explicitly disambiguate. |
| 21:29 | <bakkot> | it's going to happen deep in the system, at some point in the future, and surface to the user as a 500 at best |
| 21:30 | <bakkot> | or a missed appointment or similar at worst |
| 21:30 | <ryzokuken 🇮🇹> | also you'd almost never be able to account for all the weird edge cases |
| 21:30 | <ryzokuken 🇮🇹> | or you'd give up altogether and this would be bad for internationalization |
| 21:33 | <bakkot> | https://github.com/search?q=lang%3Ajs+%22.constructor+%3D%3D%3D%22&type=code |
| 21:34 | <bakkot> | many many people write x.constructor === Thing |
| 21:34 | <Michael Ficarra> | then get yourself on the queue bakkot |
| 21:35 | <ljharb> | sure. but if they write it with .constructor omitted, they'll immediately get the wrong result, so they won't come to rely on it |
| 21:35 | <bakkot> | not if they do if (x.constructor !== Iterator) x = Iterator.from(x), like I said the other day |
| 21:35 | <bakkot> | it is very easy to write code which will appear to work and then break later if we add .constructor |
| 21:36 | <ljharb> | that specific code wouldn't suddenly break if we added .constructor |
| 21:36 | <ljharb> | since Iterator.from(x) would be a conceptual noop in that case, i believe? |
| 21:37 | <littledan> | honestly I'm 50/50 and could go either way on this question, at this point. |
| 21:37 | <Michael Ficarra> | nicolo-ribaudo: that contradicts what mark said |
| 21:37 | <Michael Ficarra> | if we get stuck with the value, we can't move to either the accessor or the data property |
| 21:38 | <nicolo-ribaudo> | if we get stuck with the value, we can't move to either the accessor or the data property |
| 21:38 | <Michael Ficarra> | yes |
| 21:39 | <nicolo-ribaudo> | Right, and I was saying that while it's true that going from omission to data property might still not be possible, going in the future from omission to accessor is still less risky than omission to data property |
| 21:39 | <nicolo-ribaudo> | (assuming that omission is a better temporary solution, and accessor is a better permanent solution) |
| 21:40 | <ljharb> | is it worth a quick temp check on omission vs accessors? (two checks, one for each) |
| 21:41 | <Michael Ficarra> | nicolo-ribaudo: I don't see why, they both change the observed value |
| 21:42 | <nicolo-ribaudo> | nicolo-ribaudo: I don't see why, they both change the observed value |
| 21:42 | <nicolo-ribaudo> | And so we would want to be stuck in an ok situation |
| 21:46 | <Chris de Almeida> | https://github.com/tc39/Reflector/issues/513 |
| 21:49 | <Richard Gibson> | i'd love some citations for "99%" |
| 21:50 | <ljharb> | for this one case sure, but it's a month every 7 years for adar 2, it's once a year for daylight savings dropping an hour, it's every time someone mistypes 31 for a 30 day month, etc |
| 21:54 | <Richard Gibson> | I was being facetious, but applying the same arithmetic gives 98.82% for non-leap Hebrew calendar months and 99.98% for hours of the year unaffected by DST transitions. All of these edge cases really are below or just about at a 1% threshold |
| 22:11 | <ljharb> | ok, but reducing human use cases to percentages seems not very kind, either way :-) |