---

name: prototype description: "Objects clone from prototypes, not instances from classes" license: MIT tier: 0 allowed-tools: [] related: [skill, room, container, character, card, simulation, constructionism, return-stack, debugging] tags: [moollm, inheritance, self, javascript, clone, deoptimization] protocol: PROTOTYPE credits:

• "David Ungar — Self language creator"
• "Randall Smith — Self language co-creator"
• "Brendan Eich — JavaScript (Self-influenced)"

---

PROTOTYPE

"Objects all the way down."

The philosophy of prototype-based inheritance: no classes, just concrete examples that you clone and modify.

---

The Problem with Classes

Classical inheritance says:

1. Define an abstract blueprint (class)
2. Instantiate it to create objects
3. Objects are "instances of" classes

But this creates problems:

• Abstraction gap: Classes describe things that don't exist
• Rigidity: Class hierarchies are hard to change
• Ceremony: Lots of boilerplate to create simple things

---

The Prototype Solution

Prototype-based inheritance says:

1. Create a concrete example (prototype)
2. Clone it to make new objects
3. Modify the clone as needed
4. Clones delegate to prototypes for missing slots

Everything is concrete. Everything exists.

---

How Self Works

Slots

Objects are collections of slots:

Copycat: (|
  name <- "Terpie".
  color <- "orange".
  meow = (| | "Meow!" |).
  parent* = catPrototype.
|)

• name, color — data slots
• meow — method slot
• parent* — parent slot (for delegation)

Delegation

When you send a message to an object:

1. Look in the object's own slots
2. If not found, look in parent's slots
3. Continue up the chain
4. First match wins

Cloning

To create a new cat:

CopynewCat := cat clone.
newCat name: "Stroopwafel".
newCat color: "tabby".

The new cat:

• Has its own name and color slots
• Delegates meow to the prototype
• Can add new slots anytime

---

MOOLLM Implementation

MOOLLM implements prototype inheritance via the Delegation Object Protocol (DOP):

PROTOTYPES.yml

Copy# In an instance directory
prototypes:
  - path: "skills/room"
  - path: "skills/adventure"
  
resolution:
  strategy: "first-match-wins"

File Resolution

1. Check local directory
2. Check each prototype in order
3. First match wins
4. State never inherits (always local)

Example: A Room Instance

Copyexamples/adventure-4/pub/
├── ROOM.yml           # Local override (shadows prototype)
├── PROTOTYPES.yml     # Points to skills/room
├── state/             # Local-only state
│   └── visitors.yml
└── (missing files delegate to skills/room/)

---

Why Prototypes for LLMs?

LLMs don't compute inheritance algorithms. They navigate files.

Prototype-based inheritance is LLM-friendly because:

• Explicit: You can see the prototype chain
• Navigable: Just follow file paths
• Concrete: No abstract classes to imagine
• Forgettable: Each lookup is independent

---

The Wisdom of Self

"The best message is no message."

Self taught us that simplicity wins:

• One mechanism (slots) instead of many
• Objects are just dictionaries
• Methods are just slots that happen to be code
• Inheritance is just delegation

MOOLLM applies this: directories are objects, files are slots, resolution is delegation.

---

Historical Context

---

See Also

• ../skill/delegation-object-protocol.md — The DOP specification
• ../skill/skill-instantiation-protocol.md — How skills become instances
• ../constructionism/ — Learning by building
• ../character/ — Characters as prototype instances

---

Further Reading

• Ungar, D. & Smith, R. (1987). Self: The Power of Simplicity
• Ungar, D. (1995). Organizing Programs Without Classes
• selflanguage.org

---

"Self is a network, not a node."