Hah that's a good question. I haven't really thought about that or explored type systems that would interact with this pattern. Would be really interested in reading about it though!
It's not just about static type systems, though. nerdponx was asking about type systems in general. It's a tricky question even for dynamic type systems. Javascript keeps reference to the constructor and the prototype, so you can determine the "type" that way, but that's not the only way a prototype-based OOP language can work. A language can work without keeping such references and instead simply copying each property on cloning. How do you determine the type of an object then? Is the type based on the presence of certain properties? Does it include the equality of the values of such properties or does just their presence suffice? Does having additional properties change the type? There seem to be many questions with arbitrary answers in making such a dynamic type system.
I think I had static type systems in mind when I asked the question, but that was helpful all the same. It seems in the case of Self it does in fact keep the reference around.
I suppose the whole point of a static type system is moot with a fully prototype-based language. Instead maybe you can enforce compile-time checks (contracts?) on the messages an object is expected to receive.
> I suppose the whole point of a static type system is moot with a fully prototype-based language. Instead maybe you can enforce compile-time checks (contracts?) on the messages an object is expected to receive.
I think if you can do the latter, you can probably do the former. By that I mean you can probably do neither.
If cloning is something you do in runtime, how can you enforce compile-time checks on the messages they're supposed to receive? Such messages are defined at runtime.
How would a type system work in that context? Or is there no such thing?