I fail to see how a user supplied value provided after shared struct creation would work. Unless you'd somehow remap types you may have already seen. IMO you'd at least need to pass your unique ID as part of the SharedStructType.prepare call. But in general I don't like strings for unique IDs, and since we already have object that carry identity across agents, I thought it'd make sense to reuse them.

I fail to see how a user supplied value provided after shared struct creation would work. Unless you'd somehow remap types you may have already seen. IMO you'd at least need to pass your unique ID as part of the SharedStructType.prepare call. But in general I don't like strings for unique IDs, and since we already have object that carry identity across agents, I thought it'd make sense to reuse them.

The API I suggested would only be for the origin trial, not the final proposal. The user supplied type identity and prototype isn't "provided after shared struct creation", but rather, the shared struct constructor isn't usable until after it is registered. This is why shared struct type creation that depends on a prototype is different from data-only shared structs. You would have to call register to make the struct type valid.

// vector2d.js
// Each shared struct type, whether data only or "prepared" has its own unique type
export const vector2Dtype = SharedStructType.prepare(["x", "y"]);

const _Vector2D = SharedStructType.getConstructor(vector2Dtype);

// custom construction behavior
export function Vector2D(x = 0, y = 0) {
  const _this = Reflect.construct(_Vector2D, [], new.target);
  _this.x = x;
  _this.y = y;
  return _this;
}

// prototype methods
Vector2D.prototype.distanceTo = function (v) {
  const dx = this.x - v.x;
  const dy = this.y - v.y;
  return Math.sqrt(dx * dx + dy * dy);
};

SharedStructType.registerPrototype(vector2Dtype, Vector2D.prototype);

// main.js
import { Vector2D, vector2DType } from "./vector2d.js";
const v1 = new Vector2D(1, 2);
const worker = new Worker("worker.js");
worker.postMessage([vector2DType, v1]);

// worker.js
// worker imports Vector2D, which causes registration as a side-effect.
import { Vector2D, vector2DType } from "./vector2d.js";

const v2 = new Vector2D(3, 4);

parentPort.on("message", ([mainVector2DType, v1]) => {
  SharedStructType.registerPrototype(mainVector2DType, Vector2D.prototype);
  assert(mainVector2DType !== vector2DType);
  assert(
    SharedStructType.getConstructor(mainVector2DType) !==
      SharedStructType.getConstructor(vector2Dtype)
  );
  assert(v1 instanceof Vector2D); // by virtue of sharing a prototype
  v1.x; // 1
  v1.distanceTo(v2); // ok
  v1.toString(); // ok
});

SharedStructType.getConstructor() is needed to allow the program to avoid duplicating type definitions in each agent/realm. I think the burden of such deduplication should be on the program, not on the engine.

If the engine had to deduplicate itself, you'd either need a user provided type identifier at "prepare" time, and a global lock around such type definitions, or you'd need to somehow be able to collapse separate definitions into a single one. In either case you'd have to figure out what to do if the shape definition does not match, and in the case of definition collapse, how do you communicate the error to the program?

By having the type definition generate the unique type identifier, you avoid all those complications in the engine, at the cost of putting more type hydration burden on the program.

That's doesn't answer my concern. What would happen if 2 types with different shapes are registered with the same user supplied identity?

This assumes the worker can be sure the incoming message is actually for that prototype, which might not be the case if there are multiple possible values for the message. This design seems very hard to implement in user code, while my suggestion is more reliable for write-once and reuse.

I think the question raised by Ashley Claymoreis relevant: how do you handle the fan in case where multiple agents setup a shared type before being introduced to each other. A forgeable type identifier in my opinion is not safe, and I'm pretty sure it'd never make it through committee. However I'm not convinced we need prototype/constructor continuity here.

How is it not a global registry?

You're assuming there is a single author to code running in an agent

All that matters is that a given struct type has the same type identity on multiple Agents, so that each Agent can bind a prototype to that type identity. Producing an instance of a struct type should be possible on any Agent, such that I could do:

// main.js
const v1 = new Vector2D(1, 2);
worker.postMessage(v1);
worker.on("message", e => console.log(e instanceof Vector2D));

// worker.js
const v2 = new Vector2D(3, 4);
remotePort.postMessage(v1);
remotePort.on("message", e => console.log(e instanceof Vector2D));

Then you expect continuity of constructor / prototype across agents

I don't understand. Each Agent would have an independent registry mapping a type identity to a prototype.

No. I would recommend continuity of the prototype across agents. Constructor doesn't actually matter.

By continuity I mean recognition of the prototype objects identity. It doesn't need to be the same in multiple agents, obviously, but an object of the type registered in agent1 and sent to agent2 is expected to have the same prototype as an object of the "same type" created in agent2. I am not convinced we need that

My concern is with regards to who mints the type identity, as that grants the right to register it. A forgeable value allows code that doesn't trust each other to interfere with each other. That code could be running in the same realm. If the type is minted by the engine, how is it recovered by the code.

How would that be compatible with bundlers?