[Grace-core] Considering Traits as Objects in Grace

[Michael Homer]

On Wed, Mar 6, 2013 at 3:51 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> HI all
At the end I realise I don't understand the example in section 5 at
all, skip to that.
> a few comments / clarifications on this (if Kim hasn't weighted in already)
> and I've thoughts of my own in an email to come...
>
>> Methods in a stateless trait can't refer to anything except "self" and
>> their own parameters. I think that means they can't access the
>> surrounding lexical scope, which means they can't use any imported
>> modules, the dialect, or any control structures.
>
> surely they'd have to - although this does raise the question about whether
> statelessness is "deep" or "shallow".  I think it's OK if statelessness is shallow,
> although I don't really like that answer in general...
But they can't. Fields are just local variables in this model, just
like module handles, or ordinary variables in scope. If you have one
you have the other. "[M]ethods inside a trait can't close over
variables other than self". If they do, they aren't stateless at all
any more. The top of section 4 even investigates allowing closing over
immutable state and dismisses it.
>> The semantics of "super" seem to become complicated at this
>> point too - combining two traits is almost always going to require
>> writing a manual initialize method for the combination.
> if we have Multiple Inheritance (MI) then we're always going to have to
> deal with this sometime. The brutally simple Newspeak model just
> linearises hard - every class has a metaoperation to get a mixin -
> another reason for the up-then-out rule: a NewSpeak class doesn't
> really know its superclass - the declared superclass is more of a
> default if the class is not used as a mixin, rathaer than an actual superclass.
I don't see a place where you could define the method, though. I
suppose you have to explicitly delegate the method to a method in an
anonymous object.
>> The bottom-most initialize method must be called implicitly by the
>> runtime system.
>
> no, in this design it is called explicitly by new.
> The initializable trait is in the pseudoclass.
This is all good as long as you're within the trait-classes framework,
but not once you get outside it. Perhaps you just can't escape from it
once you're there, but then I don't see what the point is - all your
objects are the same.
>> It will re-trigger any parent initialize methods
>
> I think the idea is "subtraits"  override *create* not new.
>
>> A class must make its fields mutable and set them during initialize
>
> right. This is made more difficult because parameters aren't passed into new & create.
So all your objects are the same when you make them, and after you run
initialize you have to initialise them. That must include the parent's
initialisation too, I guess.
> I guess this is ameliorated in a stateless trait. no inheritance from concrete classes style,
> because all the fields will only ever be in the leaves...?

I've realised I actually don't understand what the code sample here is
doing. "initialize" is defined in the "initializable" trait, but never
called. The object returned from "create" defines a (confidential)
initialize method that calls super.initialize, but doesn't inherit or
use anything, so there is no super. Is super only rebound when a scope
uses "uses"?
-Michael