<p>If I use a class-based system, I know what shape an object will be at the time I construct it, and I know exactly which fields and methods it has. They can be put in fixed locations that remain stable, and the object has a single identity its whole lifetime.</p>
<p>In a prototype-based model, an already-constructed object can be used as the parent (prototype) of <em>another</em> object, which inherits from it. Because of this, the object being used as a prototype can become part of a new object, with a new identity and new shape, during its lifetime. It can also be inherited from multiple times by different children.</p>
<p>Understandably, the typical approaches to representing class instances where all these things are fixed at construction time don't work as well here, so what should I do instead? Do I have to use string lookup and/or just chain manually from the deepest descendant, or is there a better representation or implementation strategy? Will these implementation details &quot;leak through&quot; to become visible to the programmer?</p>
<hr />
<p>Here I'm envisaging a language where objects can be created directly with something like an object literal, and you can use an object you made that way as a prototype for others (as well as objects themselves made from prototypes). I'm open to typed or untyped approaches or varied semantic models for how that's all accomplished if needed — that's what might be leaking through from the required implementation.</p>

<object-oriented><inheritance>
How should I represent objects under prototype-based inheritance?
CC BY-SA 4.0
2024-07-17T19:42:50.637Z
Could you please clarify whether the shape of your objects should be static, and whether the prototype of an object is mutable or fixed at creation time?
Bergi
CC BY-SA 4.0
2023-05-20T22:55:50.517Z
JavaScript is an important language with [prototype-based inheritance](https://en.wikipedia.org/wiki/Prototype-based_programming). That article also has examples of what this means in practice.
l0b0
CC BY-SA 4.0
2023-05-21T06:10:07.370Z
This seems to be comparing apples to oranges ─ you're assuming the class-based system is statically typed so you always know the shape of an object when you instantiate it, and presumably always know the shape of a superclass when you extend it ─ but then comparing it to a prototype-based system where you *don't* necessarily know the shape of an object you use as a prototype for another object. Creating objects with dynamic prototypes is akin to instantiating dynamic classes, both are possible in a dynamic type system but generally not possible in a static type system.
kaya3
CC BY-SA 4.0
2023-05-21T06:16:53.770Z
@kaya3 I don't think so. Even in a dynamically-typed system the class doesn't instantiate the object without knowing what its superclass was (or at least, that's not common). The resulting shape is known at construction even if not earlier. Even in a statically-typed prototype-based system the *parent object* can become (part of) a new object with unanticipated structure, and the parent has no opportunity to anticipate that. It can also be the prototype of multiple objects of different types. If there's an obvious path around that please do post the answer, it's not obvious enough to me.
Michael Homer
CC BY-SA 4.0
2023-05-21T06:20:50.643Z
I recognise that in E-style "delegation" (forwarding) prototyping it doesn't come up and nor does identity change, so I suppose that in principle that's an answer.
Michael Homer
CC BY-SA 4.0
2023-05-21T07:34:31.450Z
I'm not sure I understand what the problem you're describing is, so I'll leave it to someone else to answer, but it does seem to me that static knowledge of the prototype's shape is the key to this.
kaya3
CC BY-SA 4.0
2023-05-21T08:01:35.757Z
@kaya3 I am trying to edit to be clearer currently. I'm not sure how to use types to get that static knowledge of the prototype's implementation - in a nominal classical system the type name can get you to the definition site, but I don't know where that level of information would come from in a prototype model without classes. I've been imagining objects are able to be created directly on their own, but I'm open to a language design choice that resolves that being part of an answer as well.
Michael Homer
CC BY-SA 4.0
2023-05-21T08:05:23.703Z
I am envisaging this as something like `let obj = Object.create(proto);` in Javascript, where `proto` is another object and so in a static type system its shape would be known. On second thoughts, there is a meaningful difference to classes, because at runtime `proto` could be an object with some subtype of the statically known shape; but `proto`'s excess properties wouldn't be accessible through `obj`'s prototype chain without a downcast.
kaya3
<p>I think a chain of hash-maps works fairly well.</p>
<p>You can optimise a little bit by pre-resolving the string lookups to indexes in the map. The <a href="https://wren.io" rel="nofollow noreferrer">Wren</a> language's VM does this. Every object gets allocated a hashmap of the same size, allowing any object to receive the same message, although if it's not supported, it's obviously a runtime error.</p>
<p>Wren is class-based, but there's no reason you couldn't use the same approach for prototypes, just copy the contents of an object rather than freshly initialising.</p>

CC BY-SA 4.0
2023-05-21T08:48:04.330Z
2023-05-21T08:48:04.330Z
springogeek
<p>I think you conflate two distinct notions in your question: prototype-based <em>inheritance</em> and dynamic <em>objects</em> that can change their shape during program execution.</p>
<p>Prototype-based inheritance itself can be rather easily implemented even in a static class-based language for instance as it was shown by Gang-of-Four as a <a href="https://en.wikipedia.org/wiki/Prototype_pattern" rel="nofollow noreferrer">Prototype pattern</a> (and/or a couple of related patterns).</p>
<p>As for (more) efficient implementation of dynamic objects (which has nothing to do with inheritance whatsoever) there's a list of options in <a href="https://languagedesign.stackexchange.com/questions/783/how-can-polymorphism-in-a-structural-type-system-be-compiled">another question</a>.</p>

CC BY-SA 4.0
2023-05-21T09:23:27.590Z
2023-05-21T09:23:27.590Z
Alex Chichigin
# How should I represent objects under prototype-based inheritance?
Posted by: username_0 on 2023-05-20
If I use a class-based system, I know what shape an object will be at the time I construct it, and I know exactly which fields and methods it has. They can be put in fixed locations that remain stable, and the object has a single identity its whole lifetime.

In a prototype-based model, an already-constructed object can be used as the parent (prototype) of *another* object, which inherits from it. Because of this, the object being used as a prototype can become part of a new object, with a new identity and new shape, during its lifetime. It can also be inherited from multiple times by different children.

Understandably, the typical approaches to representing class instances where all these things are fixed at construction time don't work as well here, so what should I do instead? Do I have to use string lookup and/or just chain manually from the deepest descendant, or is there a better representation or implementation strategy? Will these implementation details "leak through" to become visible to the programmer?

---

Here I'm envisaging a language where objects can be created directly with something like an object literal, and you can use an object you made that way as a prototype for others (as well as objects themselves made from prototypes). I'm open to typed or untyped approaches or varied semantic models for how that's all accomplished if needed — that's what might be leaking through from the required implementation.
**Tags:** object-oriented inheritance
> **Comments:**
> **username_2**: JavaScript is an important language with [prototype-based inheritance](https://en.wikipedia.org/wiki/Prototype-based_programming). That article also has examples of what this means in practice.  
> **username_3**: This seems to be comparing apples to oranges ─ you're assuming the class-based system is statically typed so you always know the shape of an object when you instantiate it, and presumably always know the shape of a superclass when you extend it ─ but then comparing it to a prototype-based system where you *don't* necessarily know the shape of an object you use as a prototype for another object. Creating objects with dynamic prototypes is akin to instantiating dynamic classes, both are possible in a dynamic type system but generally not possible in a static type system.  
> **username_0**: @kaya3 I don't think so. Even in a dynamically-typed system the class doesn't instantiate the object without knowing what its superclass was (or at least, that's not common). The resulting shape is known at construction even if not earlier. Even in a statically-typed prototype-based system the *parent object* can become (part of) a new object with unanticipated structure, and the parent has no opportunity to anticipate that. It can also be the prototype of multiple objects of different types. If there's an obvious path around that please do post the answer, it's not obvious enough to me.  
> **username_0**: I recognise that in E-style "delegation" (forwarding) prototyping it doesn't come up and nor does identity change, so I suppose that in principle that's an answer.  
> **username_3**: I'm not sure I understand what the problem you're describing is, so I'll leave it to someone else to answer, but it does seem to me that static knowledge of the prototype's shape is the key to this.  
> **username_0**: @kaya3 I am trying to edit to be clearer currently. I'm not sure how to use types to get that static knowledge of the prototype's implementation - in a nominal classical system the type name can get you to the definition site, but I don't know where that level of information would come from in a prototype model without classes. I've been imagining objects are able to be created directly on their own, but I'm open to a language design choice that resolves that being part of an answer as well.  
> **username_3**: I am envisaging this as something like `let obj = Object.create(proto);` in Javascript, where `proto` is another object and so in a static type system its shape would be known. On second thoughts, there is a meaningful difference to classes, because at runtime `proto` could be an object with some subtype of the statically known shape; but `proto`'s excess properties wouldn't be accessible through `obj`'s prototype chain without a downcast.  
> **username_1**: Could you please clarify whether the shape of your objects should be static, and whether the prototype of an object is mutable or fixed at creation time?  
---
## 2 answers
### Answer by username_4 on 2023-05-21. Score: 2
I think a chain of hash-maps works fairly well.

You can optimise a little bit by pre-resolving the string lookups to indexes in the map. The [Wren](https://wren.io) language's VM does this. Every object gets allocated a hashmap of the same size, allowing any object to receive the same message, although if it's not supported, it's obviously a runtime error.

Wren is class-based, but there's no reason you couldn't use the same approach for prototypes, just copy the contents of an object rather than freshly initialising.
---
### Answer by username_5 on 2023-05-21. Score: 1
I think you conflate two distinct notions in your question: prototype-based *inheritance* and dynamic *objects* that can change their shape during program execution.

Prototype-based inheritance itself can be rather easily implemented even in a static class-based language for instance as it was shown by Gang-of-Four as a [Prototype pattern](https://en.wikipedia.org/wiki/Prototype_pattern) (and/or a couple of related patterns).

As for (more) efficient implementation of dynamic objects (which has nothing to do with inheritance whatsoever) there's a list of options in [another question](https://languagedesign.stackexchange.com/questions/783/how-can-polymorphism-in-a-structural-type-system-be-compiled).
---
