[Grace-core] Fwd: [important] Traits

[James Noble]

On 12/03/2013, at 17:27 PM, Marco Servetto wrote:

> I would like to discuss this proposal much more.

good

> In particular, how much this is "defined" or "to be understood" as flattening?

flattening with super and lexical scoping

> some detail stuff
> 
> 1)this code
> def catFactory = object { method cat(name) { return object Cat(name) } }
> remember me this (more) Java code:
> def catFactory = new { method cat(name) { return new Cat(name) } }

they would mean the same, well the Java syntax is 

new Object() { Cat cat(name) { return new Cat(name) }   or something. 
I try not to write Java any more. 

> And, even in this pseudo Java syntax you can add new definitions, as in
> def catFactory = new { method cat(name) { return new Cat(name){....} } }

yep

> wrote in this grace proposal as
> def catFactory = object { method cat(name) { return object{ inherits
> Cat(name) ....}   } }

yep

> 2) trait "expressions" as methods:
>>> but: * we will need exactly the same static constraints from factory methods
>>>   * remember traits can't themselves be objects and you can't inherit from objects.
> I really think we can have a predefined class "Trait" that can answer
> the messages for traits composition operators.

yes we can.   Traits are then instances of that Trait class.
We still need to encode classtypes somehow - either as Trait<Defined,Required,Final> or something else.


> This will make everything very smooth, in my opinion.
> Then the type system will check that the expression after the
> "inherit" (or better "use") keyword returns a trait.

yes.

> And in a "dynamic" setting, well we will have a dynamic error, as in
> object{ inherits 1+2 .... }

there are still (at least) two questions we have to think about:

 - how dynamic do we want trait expressions to be?   The simplest answer, that has the least rules in the language
    is to make traits fully first class, and trait expressions fully dynamic.  But this will make static typechecking
    hard, and any kind of serious static compilation impossible. 

 - then once traits are first class, why do we want factories?   Instead of making and passing around a factory
 (one of the objects with a method that creates a trait), why not just pass around the class itself? 

 - alternatively, again, back to Java: class/trait names are static, and perhaps we have special typedefs 
    and rules about reaching traits via module paths or something to handle abbreviations.

at this point,I'm less convinced this is simpler to explain or understand than e.g. the factory method proposal,
which may have satanic contextual semantics, but where those semantics are confined to only a small part
of the language. 

 J