planned agenda for tomorrow's meeting:

• method sharing and prototype lookup
• property redefinition (and freezing)
• R&T interaction

Regarding the "shared modules" suggestion. I may have jumped a few steps ahead in my reasoning without explaining how I got there, so I'll take a few steps back.

If we imagine an implementation of shared structs that contains some form of methods, what can those methods close over? Only globals? What about functions that are siblings to the shared struct? What about imports?

If we do not close over these things, the methods of shared structs won't be able to reuse useful utilities such as common vector math operations you might use in a 3D graphics library, that aren't somehow patched into globalThis.

If we do close over these things, how do we ensure the module graph has been instantiated on the worker thread? What about initialization logic that might be needed that wires together some of these modules, applies polyfills, etc.? What if these modules contain top-level await or must otherwise be loaded asynchronously?

How and when do we instantiate the thread-local (or per-realm?) prototype for each struct, especially if doing so might kick off this kind of module loading in the worker?

The leap in logic I took to the "shared module" approach was to address these concerns.

• "Shared modules" would have an identity in the module cache that could be used as part of the type identity.
• "Shared modules" would promote code reuse.
• "Shared modules" would be restricted to containing only those things that can safely be shared, i.e. references to globals (which would be re-bound per realm), local functions, variables, shared structs, and imports/exports from other "shared modules".
• Due to the nature of the above restrictions, "shared modules" avoid accidental references to non-shared code.

It could be that the idea of isolating shared code to its own file is overkill, but many developers are already used to doing this with things like protobuf today (i.e., maintaining their protobuf schema in a separate file).

My answer to this closing over/loading question was, the other side which receives the object has three options for handling module loading:

• The receiving side already expected that the object would come, so the module where the shared struct is defined has already been loaded, and the receiving module can start using it immediately.
• [I honestly can't think of a use case for this, but ] The receiving side sets itself up to handle objects dynamically, so it queries the object it received for the module specifier, await import()s that, and then can use the methods.
• The receiving side just wants to use the plain old data, and can do so without importing anything.

In all cases, there are no particular restrictions in what is closed over (just by construction because we do this whole dance per module map). And there just is no such thing as shared code, no limitations on mutating the local copy of the shared classes, or on TLA (because no synchronous module loading is ever used, just normal async). It does depend on one or other type of identity (which could be URL, or module block, or symbol if we have a global mapping).

What do you see as the downsides of this option?

What about initialization logic that might be needed that wires together some of these modules, applies polyfills, etc.?

I don't have a solution to this; I was assuming that you could somehow bake this into the module.

The receiving side already expected that the object would come, so the module where the shared struct is defined has already been loaded, and the receiving module can start using it immediately.

This is probably reasonable, as long as you can reliably correlate a shared struct type in both realms by module id and export name. However, that would potentially restrict shared struct definitions to only be at the top level of a Module, since returning them from a function call might not necessarily result in the same identity being valid.

[I honestly can't think of a use case for this, but ] The receiving side sets itself up to handle objects dynamically, so it queries the object it received for the module specifier, await import()s that, and then can use the methods.

This seems like a poor developer experience.

• Remembering to include the import
• The main process changing the data it sends to the worker (depending on how the app is structured)
• Middleware that might run before application code is loaded.