[Grace-core] inheritance for stateless traits and beyond

[Andrew P Black]

On 26 Jun 2015, at 00:09 , James Noble <kjx at ecs.vuw.ac.nz> wrote:

> I’m not ignoring it. 
> The question are
>  - which problems that traits solve do we need to solve?


There is a simple example in the paper, IIRC.  It's certainly in the preface to the attached talk — the first 10 slides or so.  It has to do with sharing code amongst graphical objects. This includes re-using wrapper code — the example uses a synchronization wrapper, but it could be anything.    We who are writing in Grace are already writing stuff more complex than this.

The collections classes in Grace contain the same method multiple times because inheritance is inadequate for sharing.

>  - 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.

>  - 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.

> for me, I think it is worthwhile combining multiple parts of objects together
> to promote planned reuse (particularly of dialects) which seems to be key to traits.

All re-use is planned, in the sense that real code (almost) always has to be refactored before it can be reused.  What's not planned is the fact that a client may want to (re)use two pieces of code that were designed for separate reuse.  This is the rational for Eiffel's deep rename operation.   For simplicity, Traits didn't support that.  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.

> 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?

> 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`

	Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150626/df3dd9c4/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WilliamsCollege.key
Type: application/octet-stream
Size: 801891 bytes
Desc: not available
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150626/df3dd9c4/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150626/df3dd9c4/attachment-0003.html>