| 01:17 | <Mathieu Hofman> | Does anyone know why we decided not to look for private fields on the prototype chain of any object? This somewhat came up in 2 different proposal discussions lately: https://github.com/tc39/proposal-class-access-expressions/issues/26 and https://github.com/ljharb/proposal-error-stack-accessor/issues/3 (the latter is for a internal slot but same idea) |
| 01:21 | <Mathieu Hofman> | It would likely break a ton of "brand checks" use cases, but the problem is that there isn't any way to even create a helper to search the prototype chain as one cannot get a "ref" for the private field. |
| 08:11 | <Ashley Claymore> | the helper would need to take a callback: `(o) => #p in o` |
| 14:26 | <littledan> | It's hard/impossible to truly preserve privacy while also working with prototype chains, especially if you want to stick strictly to object-like semantics and not invent on a new thing. Also, the SES crowd insisted on WeakMap analogy semantics in particular, which has no prototype chain walk. |
| 16:47 | <ljharb> | also if it used the prototype chain then they wouldn’t be private fields, they’d be public ones, because anything can extend anything else at any time |
| 16:54 | <littledan> | well, the space of possibilities is large, but yeah we had trouble finding a mechanism that would preserve privacy, have inheritance and have a number of other properties that people were interested in |
| 20:39 | <Ashley Claymore> | also if it used the prototype chain then they wouldn’t be private fields, they’d be public ones, because anything can extend anything else at any time |