© Kevin Mehall and the Splash Contributors
Splash's object model is prototype-based, similar to Self or Javascript. Values are immutable.
Mutability is acheived through the use of identity (similar to Clojure's refs). Functions can specify that they only want values, and identity will be stripped on the passed parameter. Identity can also be simulated with values, allowing for flexibility. This reification of identity allows for simpler programming that has the benefits of functional programming while making mutation easy and safe.
Splash values are immutable, and the implementation is free to substitute one value for another, as long as they are indistinguishable from inside the VM. This means they can be passed between threads without concurrency control, and can be freely shared over the network.
In purely-functional programming languages, notably Haskell, everything is a value. This has its benefits, but is ultimately not practical. To do many things in Haskell, monads must be used to simulate mutable state.
The other extreme, taken by most mainstream object-oriented languages, is that all values are mutable. This has problems with concurrency as we enter an era of massivly-parallel computing. Mutability makes transparent distributed computing impractical, and multi-core programming error-prone.
State and mutability are really matters of identity: When data can be modified, it becomes important which data is modified. If mutabilty is allowed, values can't be transparently substituted for each other, or transparently duplicated, because those would cause the modification to be visible to either too many or too few other parts of the system. "Objects" in traditional object-oriented languages bundle identity and value too tightly, while pure functional languages have to simulate identity with tricks like monads and carefully threading objects in and out of functions.
Splash values consist of named slots. Names can be strings, but are typically symbols that associate the name with a module. Slots hold pointers to other objects.
Implementation note: The implementation is free to store the slot names in a "map" structure shared among all objects with the same slots.
Refs are mutable cells. They may be read or set. (there are additional operations that optimize concurrency; TBD.) Method lookup is passed directly through to the object to which they point.
Multimethods dispatch based on object identity. Identity is determined based on whether it is possible to distinguish the objects from within the VM. For values, this is value equality, and for refs, identity.
Slots have a parent flag. If set, failed method lookups in the value will proceed to the object pointed to by this slot. Inheritence proceeds in order of the slot's priority (to be defined), forming an an inheritence graph of all objects that are part of the value's identity. If a parent is included in the inheritence graph multiple times, it is equivalent to if it were inherited once, at the lowest priority position. Cycles in the inheritence graph are errors. (this may change)
Parent slots are not required to be named.