| 00:29 | <styfle> | I don't think anyone will ever be able to top XMLHttpRequest. It has uppercase and pascal case. Not to mention its not related to XML at all. 😂 |
| 03:19 | <kriskowal> | Ah, so you have not heard of SpOnGebObcAsE. |
| 03:20 | <kriskowal> | Ah, well, an argument can be made that XMLHttpRequest is worse. |
| 07:28 | <Mathieu Hofman> | I am concerned about some proposals going for Stage 1 at the upcoming meeting with a particular API name as the proposal name. Please don't do this. Proposals should be named after the problem they're solving, not the champion's assumed or preferred solution at the time of presenting for Stage 1. |
| 07:29 | <Mathieu Hofman> | I guess promise predicate would be an option for the proposal name |
| 12:32 | <Michael Ficarra> | I have one of those, but I really can't imagine another name given the isError and isArray precedent. |
| 14:02 | <Michael Ficarra> | I also opened an issue about how I think isPromise isn't actually the best name for the API, which reinforces my point about the proposal name https://github.com/mhofman/proposal-is-promise/issues/3 |
| 16:09 | <TabAtkins> | I mean, I'm not sure how much more generic one would have been able to make a proposal that was initially about whether or not something was a promise. If the proposal ends up significantly genericizing, that's just something unpredictable. |
| 16:18 | <Michael Ficarra> | Read the motivation for the proposal in the README. It's about detecting whether the value is treated specially by await. isPromise is clearly an assumption about how we would do that. |
| 16:18 | <TabAtkins> | I mean, sure, but also I think it's a very reasonable assumption that "await cares about promises" |
| 16:18 | <TabAtkins> | (in some way) |
| 16:19 | <Michael Ficarra> | I'm also not trying to pick on @Mathieu Hofman or this proposal in particular. At the time of writing my original complaint, I hadn't even read the proposal. |