prototype

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