| 03:15 | <rniwa> | Domenic: yt? |
| 04:09 | <annevk> | Domenic: TabAtkins: there's a bunch of low-level terms that don't really belong anywhere specifically. I oft wonder if we should create a Terms Standard or some such to collect them and define case-sensitive, ASCII uppercase, etc. |
| 04:10 | <annevk> | Also yeah, an issue would help |
| 13:00 | <tobie> | annevk: +1 to "terms standard" |
| 13:01 | <tobie> | annevk: or whatever it would be called |
| 13:15 | <tobie> | is "Return |function|.\[[Call]](|map|, |arguments|)." |
| 13:15 | <tobie> | a correct replacement for: |
| 13:15 | <tobie> | "Return the result of calling the \[[Call]] internal method of |function| with |map| as |thisArg| and |arguments| as |argumentsList|." |
| 13:16 | <tobie> | Last step of: https://heycam.github.io/webidl/#dfn-forwards-to-the-internal-map-object |
| 13:17 | <tobie> | ^ Domenic |
| 15:40 | <Domenic> | tobie: yes, however, these days it's even better to do Call(|function|, |map|, |arguments|) using https://tc39.github.io/ecma262/#sec-call |
| 15:41 | <Domenic> | There's a whole slew of these forwarding helpers, Call(), Get(), HasOwnProperty(), etc. which mostly just do minor things like assert preconditions or default arguments for you or similar |
| 16:28 | <tobie> | Domenic: cool, thanks. |
| 17:01 | <tobie> | When are the ! (return abrupt?) and ? (whatever that one does) constructs useful? |
| 17:43 | <annevk> | tobie: ? means that you rethrow |
| 17:44 | <annevk> | tobie: ! means that you know it's not gonna throw |
| 17:50 | <tobie> | annevk: oh. It looked way more complicated than that on the ES side. :D |
| 19:28 | <gsnedders> | does anyone have any stats on scripts in SVG? |
| 19:31 | <gsnedders> | like, how common they are, what % of SVGs |
| 20:06 | <tobie> | Domenic: wouldn't it be more appropriate to set the [[Extensible]] slot to false and not touch the methods instead? |
| 20:08 | <tobie> | Domenic: re https://github.com/heycam/webidl/pull/197 |
| 20:30 | <Domenic> | tobie: the idea is actually to stop you from setting the extensible slot to false |
| 20:31 | <Domenic> | I.e. stop Object.preventExtensions and friends from doing so. |
| 20:32 | <tobie> | Yes, this is absolutely obvious in retrospect. Guess I had a brain fart along the way. |
| 20:36 | <tobie> | Domenic: So what you want to do is basically turn [[PreventExtensions]] into a noop that returns false (it failed to set [[Extensible]] to false) to trigger the TypeError in SetIntegrityLevel. |
| 20:37 | <Domenic> | Yes exactly :) |
| 20:37 | <tobie> | Domenic: which is what you've been saying all along, but now I understand why. |
| 20:37 | <tobie> | :) |
| 20:37 | <Domenic> | (It's gotta return false so callers know that you're refusing to prevent extensions) |
| 20:39 | <tobie> | Domenic: I hadn't realized that the return value of [[PreventExtensions]] was whether the operation had succeeded or not. |
| 20:39 | <tobie> | Got confused by the sentence that read: |
| 20:41 | <tobie> | If [[PreventExtensions]] returns true, all future calls to [[IsExtensible]] on the target must return false and the target is now considered non-extensible. |
| 20:43 | <tobie> | it does make sense now that I read it, but anyway. |
| 21:00 | <younder> | ok |
| 21:01 | <younder> | confusing to me too |