[Grace-core] "Classical" Inheritance for Grace

[James Noble]

> If we agree on that, then self in the initialization expressions is still not an object.
> So, *may be* should simply not be visible.
> >Our semanatics are at least safe, if permitting dynamic errors.
> Our semantic require "multiple levels of contracts" for each different possible initialization status.

the problem isn't that simple. We can define the problem away -
and programmers will then just have to code things up with option types.
(make their own nulls).  This has to be about engineering tradeoffs.

> >can you expand on this here?
> Clearelly (trait/mixin) code composition is enough to reuse code as much as we can ever ever desire.

...

> -initialization order
> -super semantic
> -how many copies of static fields/methods
> I strongly believe flattening is much simpler (and modular) than delegation.

we don't have static (so far!)

we're talking mostly about initialization order here (and the binding of self) 
it seems what we're proposing here is compatible with flattening 

marco's right: we haven't (re)opened super. I can see super makes flattening
harder & less clear, but not that it makes it impossible.

> >well Newspeak has this going today, so I understand.
> So, do you agree that placeholders are as expressive as futures or not??

nope. 

> >Getting a dynamic exception is fine - the question is when are those exceptions raised?
> There is *no way* a method can be called on a placeholder, even if those method could not access fields.
> The Dynamic type of the object the placeholder will be replaced with is still *not known*; that is why placeholders are so good with object algebra.

well these are design choices.

> >so that at least the parser combinator examples could run. 
> If you have the placeholders exceptions, there is no problem at all.
> you can simply write
> exp::=  P(num) | P(exp)+P(exp)
> num::=....
> where P is an object that takes the placeholder and forward (some) method calls to the placeholder, while reponding directly to the (parser combinator) operators

which is what we do now with the "rule {}" proxy.

But I don't want to write that: I want to write exp :== num | exp + exp 

J