[Grace-core] The Raw and the Cooked - Was Re: Considering Traits as Objects in Grace

[James Noble]

> I'm not sure which note this was referring to.

note 5 - special "raw" methods...

> There is an argument
> for methods being treated as lexically bound at this point as well -
> but then why not inherited methods too, which brings you back to the
> start.

yep...

> Does this mean you can have methods called *before* state is added somehow?

it shouldn't...

> In the current design there is also no such thing as fields -
> everything is lexically scoped.

yes I know, but I forget that (or at least don't think like that)

>> it is never visible that they were once distinct, or that their structure has changed.

> The merge itself seems like it will be (dynamically) pretty
> complicated to arrange, although possible.

the hope is that static rules mean that there is no merge - 
you create a single object / single identity with the final structure,
run all the initialisation code on that object --- checking dynamically 
it doesn't break any of the rules. I think that might mean some programs
will fail differently, but should not change the behaviour of "correct" programs.

>> def baz = foo | bar     // if foo and bar are raw or placeholders, can't request "|" on foo.  oops.

so this was more related to Marco's placeholders for circular initialization.

Marco writes:
> 
> what about something like
> def baz = options foo | bar | baz
> where options is a function that takes foo and return an object that


which is more or less what you do in the ECOOP paper - 
| is a static function not a message to foo - 
but Grace doesn't work that way...

back to Michael

> Why not? Surely that just cooks foo, which is an object that is
> already fully initialised.

it's probably OK. If foo itself is a placeholder when that happens,
it doesn't understand "|".

>> which would bring in the object as raw. Each such import would bring in a *new* raw instance.
>> Then you can inherit from that raw instances as you like.

> This feels like a bit too much of a hack.

yes it is, but it has fewer problems then e.g. committing to general delegation as part of the language
(or some new form of delegation with controls to avoid breaking encapsulation etc)

>> note 4 - structurally static breaks the story that the repl is just inside a normal grace object.
>> Repls where you can incrementally define variables etc aren't structurally static.  SO we'd
>> have to cheat for repls.  I'm not sure about top-level modules / scripts - would they still
>> work, or not?
> Only if your program never actually does anything, or only calls
> methods on imported objects. At the least, stopping you from calling
> your own methods breaks the model there.

right - and there doesn't seem to be an obvious tweak to get around that...  J