3 ms·

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 re

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!

nerdponx 7y ago
It seems like the answer is "not well, and it's not recommended": https://softwareengineering.stackexchange.com/questions/95126/how-does-a-static-type-system-affect-the-design-of-a-prototype-based-language https://softwareengineering.stackexchange.com/questions/9512...
- jolmg 7y ago
  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.
  - nerdponx 7y ago
    I made both comments! 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.
    - jolmg 7y ago
      > I made both comments! Ha! I did not notice! XP > 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.
      - nerdponx 7y ago
        Does it have to be at runtime? Is there any point to an ahead-of-time compiled prototype language?

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!

nerdponx 7y ago

It seems like the answer is "not well, and it's not recommended": https://softwareengineering.stackexchange.com/questions/95126/how-does-a-static-type-system-affect-the-design-of-a-prototype-based-language https://softwareengineering.stackexchange.com/questions/9512...

jolmg 7y ago
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.
- nerdponx 7y ago
  I made both comments! 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.
  - jolmg 7y ago
    > I made both comments! Ha! I did not notice! XP > 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.
    - nerdponx 7y ago
      Does it have to be at runtime? Is there any point to an ahead-of-time compiled prototype language?