<div dir="ltr"><div class="gmail_extra"><br>
>The question is: do we e.g. mandate dynamic and permit static checks to detect this,<br>>or do we (again) change the initialization semantics.<br></div><div class="gmail_extra">This is not the question. <br></div>

<div class="gmail_extra">The question is "what is the semantic of an object? is not a thing that encapsulate a coherent state and respond to messages, both changing or exposing its state, or sending messages to other objects?<br>

</div><div class="gmail_extra">If we agree on that, then self in the initialization expressions is still not an object.<br></div><div class="gmail_extra">So, *may be* should simply not be visible.<br></div><div class="gmail_extra">

>Our semanatics are at least safe,
if permitting dynamic errors.<br></div><div class="gmail_extra">Our semantic require "multiple levels of contracts" for each different possible initialization status.<br><br></div><div class="gmail_extra">>can you expand on this here?<br>

</div><div class="gmail_extra">Clearelly (trait/mixin) code composition is enough to reuse code as much as we can ever ever desire.<br></div><div class="gmail_extra">Trait semantic is (should be) given as flattening, i.e. during compilation/before the first object instantiation of a certain class the "inherit" or "use" keywords<br>

</div><div class="gmail_extra">are removed and the "resulting" class is computed.<br></div><div class="gmail_extra">(Of course implementation can follow a different road but the semantic should be this one)<br>
</div>
<div class="gmail_extra">On the other side (classic) inheritance works by delegation, and delegation is used to understand the issues about <br></div><div class="gmail_extra">-initialization order<br></div><div class="gmail_extra">

-super semantic<br></div><div class="gmail_extra">-how many copies of static fields/methods<br></div><div class="gmail_extra">
<div class="im">I strongly believe flattening is much simpler (and modular) than delegation.<br><br></div><div class="im">>no I don't think it is.<br>
</div><div class="im">>> But in a naive implementation, instead of a placeholder exception you *wait forever* for the future to be completed....<br>
>well Newspeak has this going today, so I understand.<br></div><div class="im">So, do you agree that placeholders are as expressive as futures or not??<br>
</div><div class="im"><br>
</div>>Getting a dynamic exception is fine - the question is when are those exceptions raised?<br>
There is *no way* a method can be called on a placeholder, even if those method could not access fields.<br>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.<br>

<br>>so that at least the parser combinator examples
could run. <br></div><div class="gmail_extra">If you have the placeholders exceptions, there is no problem at all.<br>you can simply write<br></div><div class="gmail_extra">exp::=  P(num) | P(exp)+P(exp)<br></div><div class="gmail_extra">

num::=....<br></div><div class="gmail_extra">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<br><br><br><br>

</div></div>