[Grace-core] Inheritance: what is it meant to be good for?

[James Noble]

Hi MIchael and all

so I'm finishing up some emails - this one has been on the queue for a while.

On 8/12/2014, at 16:10 pm, Michael Homer <Michael.Homer at ecs.vuw.ac.nz> wrote:

> (Summary: List what you want the inheritance system to allow and facilitate.)

So here's a few design principles and use cases:

Principles: 
 * Explicable - we should be able to explain how it all works
 * Simple - students can explain / understand how it works 
 * Best Practice - the design should embody best practice 
     (we should make our own mistakes, not replicate mistakes from other languages)
 * Minimal - as simple as we can get away with
 * Nixonian - the operational semantics should impose few validity constraints so we can execute as many semantically "invalid" programs as far as possible. 
 * Alan Kay's quote - "Simple things should be simple. Complex things should be possible."  So I made two use case lists below, based mostly on the patterns papers Michael & I wrote about object creation. 

Pseudo-principles:
 * Metamodel to be based on self-sufficient objects (rather than classes, without meta-regress)
 * Provide a "class" constuct or people will invent their own (JS, Lua, Tcl...) 
[Ok these last two are cheating]


Simple Use Cases:
 - create a singleton object
 - create several similar objects
 - create and initialise similar objects with differing initial states --- encapsulating as much as possible of the implementation of the objects being created (aka "factory method") 
 - define a new kind of object (aka "class") by extending a previous definition (aka "inheritance" :-) 

Complex Use Cases:
 - create and initialise similar objects in different ways (aka "multiple constructors" )
 - create and initialise many different kinds of objects in the same way (aka "Abstract factories")
 - create many kinds of objects that differ primarily in type  information (aka "generic classes") 
 - share partial defintions across several classes (aka plain traits, multiple inheritance)
 - abstract superclasses
 - abstract superclasses whose code registers subclass instances
 - abstract superclasses whose code registers blocks
 - create and extend many different objects together (aka class families)

The trick, of course, is to support all the use cases we want, without overly prejudicing the other goals.  
This is of course impossible.

I'm really offline until the end of next week (around the 12th) and not back nominally until Feb-ish.

James