[Grace-core] Considering Traits as Objects in Grace

[Michael Homer]

These have made it clearer to me, but I have a couple of questions
they bring up.
On Thu, Mar 7, 2013 at 8:20 AM, Andrew P Black <andrew.p.black at gmail.com> wrote:
> At PDX, in the United Club ... let's see if I can clarify this before I
> leave for Denver.   It's clear that I shouldn't have released this draft
> yet, because it's
> obviously confusing, but at least it gives me a list of things to explain
> better in the next revision.
>
> On 5 Mar 2013, at 02:19 , Michael Homer wrote:
> > Methods in a stateless trait can't refer to anything except "self" and
> > their own parameters.
> No, that's not what I meant.   If we restrict traits to being stateless (and
> this may or may not be a good idea),
> then trait objects cannot access mutable state.   They can most certainly
> access other immutable objects, and I'm assuming that
> most dialects will be immutable, so they will have access to control
> structures.   Methods defined inside other methods can access
> the parameters of the outer method, in addition to their own parameters.
The second paragraph of section 4 explicitly denies that they can
capture references to immutable objects, so that should change if you
want them to certainly access them.
> I suspect that this restriction makes sense only if we actually introduce
> immutability into Grace as a formal restriction
> on the full language.   We haven't yet discussed doing this, although it's
> been hovering in the background for a long time.
Ok. The idea would be that they can access a def in scope iff the
value of that def is an immutable object? There is a pretty deep and
invasive change required to make that work, though.
> > It is, though, where you can do registration.
> > The initialize method must be called explicitly in the inheritor's
> > initialize method.
> The example was supposed to show that the initialize method is requested by
> the factory method, so that the
> client does not have to explicitly request it.  Indeed, this is the whole
> point: in Kim's window example, he does not
> want the student to have to remember to request the method that registers
> the window.
When you write a subclass you have to call it explicitly somewhere
though, right? I thought that was what he was trying to avoid. I
suppose a subclass with the same factory method and no parameters to
use can piggyback on the parent factory method.
> I didn't explain what super meant.  I think that
> (0) super is the name of the trait object that I'm using
> (1) super.meth1(args) means super^meth1(args) using ambient talk notation,
> that is,
>      delegate meth1(args) to the object super.
Is super the lexically nearest trait object then (rather than limited
to the trait used by the current object)? If it is I think it should
have another name to avoid confusion later on.
> The issue is: how often will that force a programer to use  a var, initialized
> in a method, rather than  a def?
Probably quite a lot, especially if that's how you deal with
constructor parameters. You may even need a second initialize method
to run afterwards. You can't abstract repeated or complex computations
to a method then either.
> Once again: I obviously need to clarify that initialize is just a method,
> and it must be requested explicitly.
I think the confusion came from the example. initialize is defined in
both the trait and the returned object and there seemed to be some
magic in making that work. I'm still not sure what the relationship
between a subclass instance and a superclass instance is though.
> > As an aside here, I currently have an "is parent" annotation
> > implemented (on def fields only), which gives essentially the
> > single-delegation behaviour described. That was a hack to make dialect
> > implementations simpler, but it provides some basis for
> > experimentation. A library could perhaps provide object combinators,
> > which could then be parent and get most of the effect of this design.
> Interesting.  I may be able to get GUnit working with this, if I can figure
> out how to use it.
You should just be able to add a field:
  def x is parent = someparent
to an object (including the module object) and have it work. To make
unqualified self calls someparent needs to be statically resolvable,
but qualified ones always work.
-Michael