Scarlet Object Model

Unlike most OO languages ScarletLanguage does not have implementation inheritance (see AlternateObjectOrientedProgrammingView for a wide-angle view of OOP). This is because ImplementationInheritanceIsEvil, especially for binary components which is a major focus for Scarlet. Objects in Scarlet are composed of interfaces and implementations. Interfaces are similar to those in JavaLanguage, but DesignByContract is supported so they include support for pre- and post-conditions. Implementations implement zero or more interfaces.

Objects are formed by aggregating together one or more implementations and treated as a single unit. The interface exposed by the object is the union of interfaces implemented by its implementations. This offers a great deal of flexibility: developers can add, remove, and replace implementations of objects defined in the standard library and components can do the same to application types as they load. It's also possible to assemble new types at runtime.

This turns out to be a nice paradigm. It's very clean because clients must use interfaces to talk to objects, and because there is no implementation inheritance it's much easier to change an implementation without breaking client code. It also offers the advantages of multiple inheritance without the accompanying complexities. It's very similar to some of the ideas expressed in UseCompositionAndInterfacesWithoutClassInheritance.

One problem with Scarlet's object model is that it is difficult to write methods that operate on the entire object. How can you write such a method when its implementations can be changed willy-nilly? In practice, this doesn't seem to be too much of an issue. Such methods are relatively rare and in most cases (clone, equality, etc.) can be handled via reflection. The only place where this seems like a real problem are constructors.

When an object is created, it should be automatically turned into a usable object: in other words it should be impossible to create an object that fails to satisfy its invariant. In general, I don't think this is possible to do in Scarlet. What happens now is that memory for the object is allocated, an instantiated method is called for each implementation, and then an init method is called if it is present. Any arguments used while creating the object are passed to the init method. This seems to work fine in most cases, but objects that have more than implementation requiring arguments to correctly construct themselves will need to use two-stage initialization.

-- JesseJones

Grr, InternetExplorer isn't adding whitespace before the third paragraph ("This turns out...") and the fifth paragraph ("When an object...") when I view the page. -- JesseJones

CategoryPolymorphism, CategoryLanguageFeature