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

# 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 · 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 — 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 — bibliography, PDF
• Smith, R. B. & Ungar, D. (1995). Programming as an Experience: The Inspiration for Self — bibliography, PDF
• Ungar, D. (1995). Organizing Programs Without Classes
• selflanguage.org
• Curtis, P. (1997). LambdaMOO Programmer's Manual — HTML (objects, verbs, and the virtual reality as a programmable database)