[Grace-core] initialisation & checking

[James Noble]

To focus(?) the discussion, here's my take on the current "2-phase, inherits exp" proposal:

This is just a repost from the start of the the month: 
I've truncated the message - which went on a lot longer & not included comments from the thread - 
all the discussion including a bunch more options is in the archive

http://mailhost.cecs.pdx.edu/pipermail/grace-core/2013-April/001014.html


So, in Denver we agreed on what we meant by "classical inheritance"
before we agreed on (or rather got dragged into) a big debate on
mechanisms:

From earlier email 
Subject: [Grace-core] [less important] Classical Inheritance vs Delegation
Date:    9 March 2013 7:54:34 PM NZDT

Some other notes from today's discussion - Kim on "classical inheritance"

> A class definition is a template for instances
> - instance variables 
> - method suite
> - some kind of parameterised initialisation code
>
> Single Inheritance:
> A subclass definition includes all of the above class definition
> - along with a single superclass
> - its method suite may override the superclass's methods
> - initialisation code in the superclass runs before the code for the subclass
>    with "self" bound to the whole new object
> - initialisation code can make self-calls, these should have the same semantics
>     as normal method calls
>
> Classes do not _have_ to be objects --- 
> they can be separate, static, non-first class.
>
> BUT: classes as objects in so far as they are factories - that "new"
> is a standard method call - is important and good.


We can keep the text of the current latest spec sections 7.1-7.3 and
7.5, putting 7.4 on hold. (Note that the spec was never updated for
"reverse become" semantics).  We keep the existing syntax:

class aCat.ofColour ( aColour ) named (aName) {
  def colour : Colour = aColour
  def name : String = aName
  var miceEaten := 0
} 

Inheritance again uses the current syntax (annotations are updated
from the spec)

class aPedigreeCat.ofColour (aColour) named (aName) { 
 inherits Cat.ofColour (aColour) named (aName)

 var prizes := 0
 method miceEaten is override {0};
 method miceEaten:= (n:Number) is override {return}
} 

What are the semantics?  Hopefully what we (what most people) expect,
what we said above: we make a whole object, including all the methods
& unitialised fields, and then we run the code in all the class bodies
top-down, starting with the uppermost superclass (that had better not
inherit from anything). The result should be an initialized object.

How do we create objects? - by writing an expression which names a
class followed by a request for its method.  The current spec includes
the timeless phrase "The right hand side of an inherits clause is
restricted to be a class name, followed by a correct request for that
class's method" - let's keep that for now - though I'll expand on it
below - and imagine similar wording for object creation: a class name
(or perhaps, an expression that definitively statically evaluates to a
"class") followed by a call to that class's method.

My point is: I think this is pretty much enough. We don't need to say
anything more - although we should, I think: this leaves too much
unspecified. But, if we wanted to, we could leave that unspecified and
be done - I do think this is the "minimal class based design" we've
been after.  We've pretty much always had it all along.

The rest of this email discusses various orthogonal issues in
inheritance, or one (or perhaps some) options for fleshing out this
design.

What this discussion intentionally omits is the "philosophical" or 
"ontological" status of classes, because basically I think that is
another orthogonal axis --- if we really feel the need to elaborate
on things, there are several sensible designs that preserve this
"classical" core.

lots more at http://mailhost.cecs.pdx.edu/pipermail/grace-core/2013-April/001014.html

including interpreting the rhs of "inherits" as a method tail-returning an object constructor...