[Grace-core] "Classical" Inheritance for Grace

[James Noble]

> I have a bunch of comments:

good!

> ------------
> 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.
> * Initialisation:
>   Defs have to be because they can't be initialised outside
> -----------
> This is fundamentally broken. (and yes most of the oolanguages are broken in this way): the initialization code in the parent class can call methods overriden by the heir. This methods will unexpectedly find defs not initialized.
> Check out Hard-hat constructors.

The question is: do we e.g. mandate dynamic and permit static checks to detect this,
or do we (again) change the initialization semantics. 

I recall either Rustan on Manuel Fandrich arguing somewhere that
classes should initialise from subclass to superclass - solves that 
problem but creates other ones.  Our semanatics are at least safe,
if permitting dynamic errors.

> ---------------------
> * Multiple inheritance 
> Can I please just assert this is orthogonal? We can do traits or ...
> -------------------
> You can at the price of having "classical inheritance" as the default way to go and more expressive code combination pattern as a weird thing to do in rare cases. If we want (trait, mixin or ...) code combination to be the only composition, based on flattening, then "classical inheritance" is not the "way to go". It is just a decision: we want a
> -simple language with classical inheritance?
> -simple language based on composition and flattening?
> -a messy union of the two?

can you expand on this here? 

> --------------------------
> Marco's placeholders... less powerful (w.r.t. newspeak futures): you bind... raw identity to each name in a first pass, and then initialize all the objects in a second pass. 
> ... you cannot do *anything* to the objects until they are assigned, they don't have any methods and you'd just get an "placeholder exception" 
> --------
> the same limitation applied to nespeak futures:

no I don't think it is.

> But in a naive implementation, instead of a placeholder exception you *wait forever* for the future to be completed....

well Newspeak has this going today, so I understand.

> A different discussion is "my typesystem" that indeed limits what you can do.
> But in a language where you accept the idea of having uninitialized field exception on reading a field.... well.. placeholder exceptions are fine...

Getting a dynamic exception is fine - the question is when are those exceptions raised?
The vanilla placeholders in the paper are very conservative, they will throw placeholder
exceptions in cases where a system that only throws exceptions upon access to 
uninitialized fields will successfully complete initialization.  Conversely, a 
placeholder exception will always be thrown before a uninitialised variable
exception would to be thrown (assuming constructors have to
assign to all the variables.   This means the ECOOP paper typesystem
would prevent uninitialized variable exceptions.
It's an interesting question (to me at least) if we could expand the type system
to accept more programs so that at least the parser combinator examples
could run.  Something for a journal paper?

James