JSONRegistry - Allows branded instances in regular JSON

I'm really spending a lot of time pointing out a genuine issue in your design, so the accusations are a bit of of place. I'm not sure where I'm failing at communicating the problem that you don't seem to understand.

Here is a more spelled our example. I assumed someone with your experience would have been able to connect the dots.

Not proofed because I really don't have time.

class Foo {
  #bar;

  get bar() {
    return this.#bar;
  }

  initBar(bar) {
    if (this.#bar !== undefined) throw Error();
    this.#bar = bar;
  }

  static isFoo(foo) {
    return #bar in foo;
  }

  static asClonePayload(foo) {
    return { bar: foo.#bar };
  }

  static fromClonePayload(data) {
    const foo = new Foo();
    foo.initBar(data.bar);
    return foo;
  }
}

class Bar {
  #foo;

  constructor(foo) {
    this.#foo = foo;
  }

  get foo() {
    return this.#foo;
  }

  static isBar(bar) {
    return #foo in bar;
  }

  static asClonePayload(bar) {
    return { foo: bar.#foo };
  }

  static fromClonePayload(data) {
    return new Bar(data.foo);
  }
}

const registry = new CloneRegistry([
  ['Foo', {
    is: value => Foo.isFoo(value),
    to: value => Foo.asClonePayload(value),
    from: value => Foo.fromClonePayload(value),
  }],
  ['Bar', {
    is: value => Bar.isBar(value),
    to: value => Bar.asClonePayload(value),
    from: value => Bar.fromClonePayload(value),
  }],
]);

const foo = new Foo();
const bar = new Bar(foo);
foo.initBar(bar);

Foo.isFoo(foo) && foo.bar.foo === foo; // true

// No way to implement this with your proposed `from` registry API.
const foo2 = registry.clone(foo); 

Foo.isFoo(foo2) && foo2.bar.foo === foo2; // should be true

as mentioned, I am not willing to talk about my JSONregistry proposal anymore, as you stated that's not going to happen, but I can tell you if the structuredClone idea, with the optional registry that doesn't require any API change, would be more welcomed, I can present a polyfill that tackles those easy to handle issues, because I have an army of converters and I am sure they tackle that. The current JSONProxy idea is dead, I am not fixing anything in there neither, because it's a no-go, accordingly to this discussion, but yet that use case would be easy to fix, but I am not doing that, 'cause it's pointless, since we nuked JSONProxy idea already and I am already a full time employee with a 4yo daughter to take care about any time I don't work ... to put in perspective what I am willing to discuss, and what I won't ... yet, I see no issue in anything you are proposing as an issue, I am afraid if that's me not fully understanding the issue, but I've solved with ease your previous puzzle, that's a library I use daily too, if there are bugs, I am willing to fix that.

I hope this answer makes sense to you, let's stop discussing JSONRegistry or JSON already, shall we? Otherwise, should I open a new issue because I won't take any action around that initial idea, since the goal was to discuss the elephant in the room: nobody can serialize custom types?

FFS, understand that my comment was not about JSON, but about the registry API.

s/JSON/Clone in the example, does that make sense now?

OK, I've seen you've changed the code ... I'll try to find time myself to understand why that wouldn't work with structured clone, thanks for the update (I don't have much time myself so I've skipped the code when I've read JSONRegistry, apologies).