[Grace-core] inheritance for stateless traits and beyond

[James Noble]

On 27/06/2015, at 10:05am, Andrew P Black <black at cs.pdx.edu> wrote:
> 
> There is a simple example in the paper, IIRC


yep. I was looking at that over the weekend. 
We could try to code that up using the current proposal.

>>  - which parts of the traits mechanism do we need to solve just those problems?
> 
> Every part that is there, we put there because it was necessary.  I would be delighted to take some part out, if it's not necessary.

Some parts seem more necessary than others! 

Clearly being able to incorporate two or more “stateless traits" into a single class - along with a superclass - is crucial.
Even Java8 can do that now.	

>> I’m less convinced on the additional features of traits (for ad-hoc reuse), many 
>> trait systems (Scala etc) don’t have that. 
> 
> What features are you thinking of?

aliases, deletion, the more complex trait operators.  
I don’t think Scala or Java have those directly. 

> Traits does have an alias mechanism, so that the client can compose two pieces of code that don't know about each other.  Michael's suggestion of naming the components (with an as clause)  is essentially equivalent, I think, and may be a better way to accomplish the same goal.

Ok right. I hadn’t thought about it like that, but I can see it.

>> Then there is the question of how to fit it in to Grace.

> That is indeed the question.  One possible approach is to move the `module.methods` convention into the language.  So if one object uses (or includes?) another, it gets all of that object's methods, but none of its state, just like inheriting from `module.methods`

so we are suggesting this for modules, especially - but not making it mandatory for every object.
A (reflexive) method like “methods” (or “clone”) is treated as method return a fresh, hence inheritable, object. 

>>  - how to incorporate those parts into the existing Grace design?
> 
> Ah, there's the question.  I think that we have made some choices that mean that there is no way forward.  We have to reconsider them.

Well, I’d like to see how far we can get on the examples from the paper. 
If you’re already writing traits as factory methods aka classes, I think we can get most of the way.

James