[Grace-core] "Classical" Inheritance for Grace

Marco Servetto marco.servetto at gmail.com
Tue Apr 2 14:10:36 PDT 2013


>The question is: do we e.g. mandate dynamic and permit static checks to
detect this,
>or do we (again) change the initialization semantics.
This is not the question.
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?
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.

>can you expand on this here?
Clearelly (trait/mixin) code composition is enough to reuse code as much as
we can ever ever desire.
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
are removed and the "resulting" class is computed.
(Of course implementation can follow a different road but the semantic
should be this one)
On the other side (classic) inheritance works by delegation, and delegation
is used to understand the issues about
-initialization order
-super semantic
-how many copies of static fields/methods
I strongly believe flattening is much simpler (and modular) than delegation.

>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.
So, do you agree that placeholders are as expressive as futures or not??

>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.

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130403/6750b0eb/attachment.html>


More information about the Grace-core mailing list