[Grace-core] inheritance for stateless traits and beyond

[PSU via GMail]

Gilad's talk at MASPEGHI was about this. He mentioned that it's nice that people reference his Thesis (Jigsaw) but it would be nicer if people read it too!

One of the ideas behind our Smalltalk Trait design is that if your Trait Vendor broke your program, say by adding a method to, or renaming a method in, a trait that you are using, then you (the client) can fix things up by subtracting the added method, renaming again, etc.

Jigsaw had both exclusion and projection, that is, you could specify either the methods to exclude or the methods to keep.  Clearly, from a mathematical point of view, these are not both necessary. But from an Engineering point of view, the necessity of both should be clear.

Andrew P Black

> On 29 Jun 2015, at 13:18, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> 
>> 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
> 
>