[Grace-core] Considering Traits as Objects in Grace

[James Noble]

HI all

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

> Stateless traits clearly aren't useful in practice then, so we must be using the
> general objects-as-traits model. In that, an object may say it "uses"
> any other object,

andrew does propose this towards the end of the paper,
but mostly talks about stateless traits. I agree we should pick one.
Note you could have stateless traits that do access the surrounding
lexical environments (which may involve state)  even if the main
object does not.

> There is this "initialize" method in objects, which can't do any real
> initialisation when there is no access to state.

I guess the idea is that code in even stateless traits can access states 
in the final pseudoinstance object. To typecheck code using traits,
we'd need some way to define (or rather require) abstract methods:
a stateless trait that wants its instance to have a def or a var 
would require one or two accessor methods.

> Immutable fields must already be initialised.

right - and I think this is a problem.

> It is, though, where you can do registration.
> The initialize method must be called explicitly in the inheritor's
> initialize method.

note that the initializable trait is mixed in to the (pseudo)class object,
not the (pseudo)instance object... 

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

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

Clients request "new" on the pseudoclass
The new method requests the  "create" hook method and then 
requests "initialize" on the result of create, the newly created 
but uninitialized object. 

def initializable = trait {
   method create is abstract { done } method initialize { done }
   method new is {
     def instance = self.create instance.initialize
     return instance
} }

> (but how defs are set then I don't know).

I think defs are set in the object constructor that is called in the create method?

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

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

Hmm: still don't see how the arguments get into the create method?

Andrew: are we missing something here.

> Traits are susceptible to the "vampire" problem, where an object's
> encapsulation can be broken open by another.

yep, this is a real problem.
I have a solution that is worse than the problem...

> I'm not sure about the block-self problem that brought up our
> inheritance issues in the first place:

I think it will be lexically in the "wrong" object

all for now....

J