| 02:22 | <Kris Kowal> | The combined effect of your preferences would be to rename referrer to context, and if that is what it takes to satisfy Caridy, I’m all for it. |
| 02:23 | <Kris Kowal> | That is, new Module(source, sharedHandler, context) where sharedHandler = { importHook(specifier, context) => Module } |
| 02:25 | <Kris Kowal> | And from a performance perspective, it doesn’t reduce allocations, but the handler object can be an ephemeral options object, which would presumably go into the nursery and get collected cheaply, instead of being retained for the lifetime of the Module. |
| 09:48 | <yulia | OOO until sept 26th> | the graph looks great! that was what i was thinking of doing but it looks like it helped you organize your thoughts. I'll read through |
| 14:52 | <yulia> | compartments layers 1,2,3 seem to have no dependencies, putting them at what I would imagine to be the same layer. Any reason they cannot be done concurrently? |
| 21:51 | <Kris Kowal> | They can certainly be done concurrently. |
| 21:54 | <Kris Kowal> | Reminder: Module Harmony meeting tomorrow. I’m hoping to share this Module Harmony Graph. |
| 21:56 | <Kris Kowal> | Putting this together has helped me tease apart some of the finer layers, which are academically interesting at least: Like, having ModuleSource instances is useful even even without a ModuleSource constructor. |
| 21:57 | <Kris Kowal> | And there are cases where the constructor might be omitted but instances would still be present, like some configurations of XS that don’t include the JS parser but would have use for import module syntax. |
| 21:58 | <Kris Kowal> | And cases where a ModuleSource instance would have CSP origin information in the underlying host data, which would not be possible to construct with the ModuleSource constructor (unless generalized to thread trusted types) |