| 09:37 | <rkirsling> | it'll take 'til next week before I can get my colleagues to fill out the Doodle but it's safe to say that at least one of the days will have more than 24 people |
| 09:58 | <Rob Palmer> | Thanks Ross. Does this also apply to the Wednesday dinner? |
| 09:59 | <Rob Palmer> | Also, the Doodle is just for advertising. If folk want to attend they must fill in the registration for. That's the one I suggest you ask them to fill in if they are coming. |
| 11:06 | <rkirsling> | er whoops. consider "Doodle" a misspeak on my part |
| 11:06 | <rkirsling> | I'm not certain that any of the three plan to attend the dinner |
| 15:12 | <mgaudet> | Q: If I were looking for well regarded criticism of Proxies as they exist in the language (perhaps retrospective "they were a bad idea"), does anyone have any pointers to things that they may not agree with but think are worthwhile viewpoints to consider (I'm seeking this as background to something I'm rolling around) |
| 15:15 | <mgaudet> | (also, to be clear, I just want to understand the shape of criticism here) |
| 17:02 | <bakkot> | mgaudet: I think Proxies were a bad idea. Basically it comes down to one thing, with two angles, namely, they make code hard to reason about. this means that a.) any implementation, tooling, or library needs to account for the possibility of side-effects in many more places than they otherwise would and b.) anyone trying to read or maintain code which uses them has to reason about the behavior of that code in a fundamentally different way than any other code. basically, they add an incredible amount of complexity to the language, and the thing you get in exchange - "now objects can have a much wider range of behaviors when interacted with" - isn't even a good thing. |
| 17:04 | <mgaudet> | Thank you :) That's a helpful comment. |
| 17:04 | <TabAtkins> | Should've just added __method_missing__ |
| 17:44 | <shu> | why only hook behavior that's missing |
| 17:45 | <shu> | __on_step__ |
| 18:19 | <Mathieu Hofman> | I do wish proxies had more strict invariants where it would become inert (traps no longer invoked) once the language invariants says the proxy cannot change its answer anymore. More specifically, there is no good reasons for most proxy traps to be invoked if the proxy is frozen. I guess I'd prefer a mechanism that allows lazily building behavior, but not change that behavior dynamically forever. |
| 18:22 | <Chris de Almeida> |
|
| 18:36 | <Richard Gibson> | I do wish proxies had more strict invariants where it would become inert (traps no longer invoked) once the language invariants says the proxy cannot change its answer anymore. More specifically, there is no good reasons for most proxy traps to be invoked if the proxy is frozen. I guess I'd prefer a mechanism that allows lazily building behavior, but not change that behavior dynamically forever. |
| 19:28 | <ljharb> | related to that, I think it was huge unwarranted complexity to require observable lookup of methods on the handler inside every operation rather than capturing those methods at proxy instantiation |