| 08:31 | <annevk> | Andreu Botella: yes, see https://tc39.es/ecma262/#sec-jobs |
| 08:33 | <Andreu Botella> | Hm, yeah, I guess the job requirements pretty much rule anything other than an event loop |
| 14:15 | <littledan> | Sure but still some people in TC39 spaces will not like to hear those words… so it is fine to have as a mental model but not how proposal spec text should be written. |
| 14:17 | <littledan> | The module map is a similar situation—the idempotency requirement on imports necessitates it exist at some level, but it is defined outside of Ecma-262. |
| 18:09 | <tolmasky> | Is there a stylistic/documentation reason that hasOwnProperty's argument is named "V", when (I think?) most other places that take a thing that is meant to be a property key (by that I mean, they immediately call ToPropertyKey() on it) use "P" instead (for example, defineProperty uses P, getOwnPropertyDescriptor, etc.) |
| 18:09 | <tolmasky> | Including, notably, hasOwn, which also uses "P" instead of "V" |
| 18:10 | <bakkot> | I don't know offhand, but probably not; parameter names are currently not particularly consistent and so I wouldn't suggest reading into them much |
| 18:39 | <jmdyck> | Object.p.hasOwnProperty was introduced in 3rd edition, where all Object.p.foo had at most one parameter, always named V regardless of its purpose. Object.{defineProperty,getOwnPropertyDescriptor} were added in 5th edition, along with other Object.foo functions. Some of these had more than one parameter, so I imagine a bit more thought went into choosing their names. So: 2 different kinds of consistency, at 2 different times, in 2 different sections. Historical accident, I'd say. |
| 19:52 | <tolmasky> | Would their be opposition to submitting changes that made it more consistent, specifically making them all P for example (for larger context, this is to make tooling I'm writing around this easier -- it would be nice to just be able to call everything "P" propertyKey or whatever, without needing to special case 3rd edition stuff with a bunch of manual overrides) |
| 19:59 | <ptomato> | I don't know if this is intentional editorial guidance, but I've seen single-letter parameter/variable names become much less common in additions from recent years |
| 20:01 | <tolmasky> | I certainly would be fine changing it to propertyKey or key or whatever too of course (I am already about to map all the P's to propertyKey, etc.) |