Prototype inheritance can beautifully express the incremental specification of computations in a branching structure of information elements. The basic principle of it can be simply defined in a hundred characters of Scheme (see issue #3), with two functions: one to compute the fixed point of an open recursion scheme (or prototype), the second to chain two open recursion schemes through inheritance. However, that simple reduction is lacking in features, whereas adding those features in a naive ad-hoc ways breaks the aesthetic simplicity of the concept.
Features one would like to have in a prototype inheritance system include:
being able to specify the slots of a structure as (mostly) independent incremental constructs.
organize the prototypes you inherit from not as a sequence you must get exactly right, but as a partial order of dependencies wherein redundantly specified super-prototypes are only used once.
being able to specify the linearization algorithm for those dependencies.
being able to specify type restrictions for prototypes, slots, etc.
being able to specify method combinations for slots.
being able to add new kinds of meta-data on prototypes, slots, etc.
indexing slots by hygienic identifiers, not strings.
supporting class-based OO as a common special case.
supporting property-based testing
supporting logical specification
specifying access controls
applying well-known optimizations to cache computations, inline common use cases, partially-evaluate method combinations, provide fast slot access for objects of known shape, short-circuit expensive general case computations when handling common special cases, etc.
for every meaningful feature of any prototype and class object systems, either supporting it somehow or explaining why it is a bad idea.
These features should be achieved as much as possible by composing independent abstractions with clean simple semantics, instead of piling features in a huge ball of mud with unfathomable complexity. An architecture that enables all these features is typically called a Meta-Object Protocol, or MOP, as made famous by the book The Art of the Metaobject Protocol (AMOP)—except that book uses classes rather than prototypes, and predates a modern functional, compositional and/or categorical approach that we want to use. Another inspiration should be Ian Piumarta's "Open Reusable Object Models". Then we could look at how things are implemented in Slate.
Prototype inheritance can beautifully express the incremental specification of computations in a branching structure of information elements. The basic principle of it can be simply defined in a hundred characters of Scheme (see issue #3), with two functions: one to compute the fixed point of an open recursion scheme (or prototype), the second to chain two open recursion schemes through inheritance. However, that simple reduction is lacking in features, whereas adding those features in a naive ad-hoc ways breaks the aesthetic simplicity of the concept.
Features one would like to have in a prototype inheritance system include:
These features should be achieved as much as possible by composing independent abstractions with clean simple semantics, instead of piling features in a huge ball of mud with unfathomable complexity. An architecture that enables all these features is typically called a Meta-Object Protocol, or MOP, as made famous by the book The Art of the Metaobject Protocol (AMOP)—except that book uses classes rather than prototypes, and predates a modern functional, compositional and/or categorical approach that we want to use. Another inspiration should be Ian Piumarta's "Open Reusable Object Models". Then we could look at how things are implemented in Slate.