| 16:39 | <yulia> | stupid question: private methods are not bindable is that right? |
| 16:40 | <Jack Works> | 🤔why not |
| 16:42 | <yulia> | you can bind them, it just takes a bit of effort, i want to check if that is right and also what the thinking was behind it |
| 16:43 | <yulia> | I think it makes sense |
| 16:43 | <yulia> | the issue is constructor patterns like this: |
| 16:43 | <yulia> | the person I am speaking with mentioned that you can't reassign private methods in the constructor |
| 16:44 | <yulia> | that is a pretty common pattern, so im checking if we got this right, and what thoughts were for this pattern |
| 16:46 | <yulia> | im wondering if we need bind in that case at all... i need to check |
| 16:52 | <yulia> | yeaeh... ok so it does become a problem with aliasing, and the arrow function is the most elegant way to deal with it |
| 16:52 | <yulia> | was that intentional? |
| 16:53 | <bakkot> | yulia: https://github.com/tc39/proposal-private-methods/issues/11 |
| 16:54 | <yulia> | bakkot: thanks, that answers it |
| 21:04 | <jmdyck> | rbuckton: RegExp stuff was added to the spec in ES3. At the time, the algorithms in the rest of the spec were written in a fairly primitive form of pseudocode (e.g., "go to" instructions, limited use of aliases, no block structure). My guess is, whoever wrote the RegExp semantics didn't want to be limited to that style. |
| 21:06 | <jmdyck> | Re "ordered pair" instead of Records: Records didn't exist in ES3. (E.g., instead of Completion Records, there was the internal Completion type, which was defined as "triples of the form (type, value, target)".) |
| 21:07 | <jmdyck> | Re "captures m" instead of using internal slots: internal slots did exist in ES3 (although they were called internal properties), but (then as now), they only belonged to objects, and RegExp semantics wasn't defining an object there. |
| 21:08 | <jmdyck> | In fact, the rest of the spec "caught up" with RegExp semantics on that point when it introduced Abstract Closures. |