Prototype

---
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.

## Lineage: Self, this skill, and multiple parents

This skill is **directly inspired by Self**. In MOOLLM, **Self is one of this skill’s prototypes**: the schemapedia **[`self` mechanism](../schema/schemas/mechanisms/self/README.md)** names that parent lineage (Ungar, Smith, and collaborators). The same **Delegation Object Protocol** applies to skills as to room instances: an ordered **`PROTOTYPES.yml`** can list **several** parent skills—Self is not the only possible parent. **Because prototype inherits from Self, it already follows the rules that let any MOOLLM object inherit from multiple prototypes** (local wins, then each parent in order, first match wins).

---

## 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.**

### Self as universal object machine

**Self** is a **universal object machine**: a minimal language of objects, slots, and delegation from which you can **implement or host** other object systems—**classes** (as conventions on top of prototypes), **CLOS**-style generic functions and method combination, **generic dispatch** lineages (**ScriptX**, **Dylan**, and related multimethod designs), **COM / OLE / ActiveX**-style component object models, **PostScript** Dictionary Stack NeWS "class.ps" Objects, **JSON** (maps of keys to values as object-shaped data), **YAML Jazz** (semantic comments beside the parsed tree in MOOLLM’s notation layer), and more. Those systems are **not** the same mechanism as Self; they are **targets** you model, embed, or bridge—Self and prototype delegation stay the bedrock.

---

## How Self Works

### Slots

Objects are collections of **slots**:

```
cat: (|
  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:
```
newCat := 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

```yaml
# 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

```
examples/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

From the abstract of *Self: The Power of Simplicity* (Ungar & Smith, OOPSLA ’87):

> *Self is an object-oriented language for exploratory programming based on a small number of simple and concrete ideas: prototypes, slots, and behavior.*

Source: [Self bibliography](http://bibliography.selflanguage.org/self-power.html) · [PDF](http://bibliography.selflanguage.org/_static/self-power.pdf)

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

| Year | Event |
|------|-------|
| 1986 | Ungar & Smith begin Self at Xerox PARC |
| 1987 | Self paper published |
| 1991 | Self 2.0 with compilation |
| 1995 | JavaScript created (heavily Self-influenced) |
| 2024 | MOOLLM applies Self to LLM filesystems |

---

## See Also

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

---

## Further Reading

- Ungar, D. & Smith, R. (1987). *Self: The Power of Simplicity* — [bibliography](http://bibliography.selflanguage.org/self-power.html), [PDF](http://bibliography.selflanguage.org/_static/self-power.pdf)
- Smith, R. B. & Ungar, D. (1995). *Programming as an Experience: The Inspiration for Self* — [bibliography](http://bibliography.selflanguage.org/programming-as-experience.html), [PDF](http://bibliography.selflanguage.org/_static/programming-as-experience.pdf)
- Ungar, D. (1995). *Organizing Programs Without Classes*
- [selflanguage.org](http://selflanguage.org/)
- Curtis, P. (1997). *LambdaMOO Programmer's Manual* — [HTML](https://www.hayseed.net/MOO/manuals/ProgrammersManual.html) (objects, verbs, and the virtual reality as a programmable database)