<div dir="ltr"><div class="gmail_extra">I have a bunch of comments:<br>------------<br>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.<br>* Initialisation:<br> 
Defs have to be because they can't be initialised outside<br>-----------<br></div><div class="gmail_extra">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.<br>


</div><div class="gmail_extra">Check out Hard-hat constructors.<br>---------------------<br>* Multiple inheritance
<br>
Can I please just assert this is orthogonal? We can do traits or ...<br>-------------------<br></div><div class="gmail_extra">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 
</div><div class="gmail_extra">-simple language with classical inheritance?<br></div><div class="gmail_extra">-simple language based on composition and flattening?<br></div><div class="gmail_extra">-a messy union of the two?<br>

--------------------------<br>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. <br>... 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" <br>--------<br></div><div class="gmail_extra">the same limitation applied to nespeak futures:<br>But in a naive implementation, instead of a placeholder exception you *wait forever* for the future to be completed....<br>


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


<br></div><div class="gmail_extra">Marco.<br>
</div></div>