[Grace-core] Semantics of object/classes

[James Noble]

> My attempts to describe how object constructors and inheritance should work are on the Wiki:

Great. I'll read those as soon as I'm on a device that's knows my password :-)

> The style is so different from what Kim sent out that I'm not sure how to compare them.   

Sure. 
> First, notice that I specified ONLY the semantics of inheriting form an object, since this is the general case, and inheriting from a a class object or inheriting from a newly-created instance of a class are just special cases.   

Well I guess that's what we're trying to decide. 

> Also notice that I deliberately left the time at which initialization code runs unspecified; we haven't talked about this, but it seems to me that specifying strictly serial execution is a premature pessimization.

The catch here is that it's imperative, side-effecting code. I think we will need to specify some order here.  C didn't specify order of evaluation for function calls and that turned out to be a mistake (at least for pedagogical purposes). 

And we need to specify the bindings for self. 

>   Another difference is that I don't write in terms of implementation issues, like when space is allocated, but only about language-level things, like when variables are bound.

Sure. 

> Although what I've written on the wiki is what I've come to understand as the semantics of what we now have in Grace, as I write more code, I'm increasingly unhappy with the current formulation of classes.  The problem is that "class side inheritance", to use a Smalltalk-ism, doesn't work right.   

We don't have any class side inheritance - although we hope you can build it out of objects. (under the current rationale). 

> If I have a superclass with a constructor method 'makeOne(x)', and I want to inherit from that superclass, then I _have to_ override 'makeOne(x)', because if I don't then I will get the SAME kind of instance from the subclass.   

So - in Grace at least - you'd need to define which object constructor you want to run somewhere. 

Smalltalk has magic to make basicNew work "right" - we'd have to build that. Then Smalltalk (and Self) don't have the kind of per-instance constant defs that we do. 

> Fixing the class syntax to specify parallel inheritance on the class and instance sides doesn't solve the problem.   And I don't see an easy solution, other than going to Smalltalk-style classes.

Newspeak-style classes? Or Scala-style classes?


> I'm now feeling that our Onward! paper was premature

We're not done yet and don't claim to be. 

James.