On Sat, Jan 4, 2014 at 1:03 AM, Ben Kloosterman <[email protected]> wrote:
>
> A trait is an interface with a method .. not static an instance methods.
>
> If you view an interface as an object with some methods eg
>
> class IEnumerable { private object collection; Enumerator
> GetEnumerator( ) { return collection.GetEnumerator() }
> }
>
> than a trait would be
>
>
> class ICollection { private Collection collection; Enumerator
> GetEnumerator( ) { return collection.GetEnumerator()
>
> public void Clear() { while collection.Count != collection.Remove() ; }
> // as opposed to calling collection.Clear()
> }
> }
>
> eg it adds type methods like inheritance.. and for the same reasons as
> inheritance id rather not have them...
>
OK. So the claim here seems to be that the implementation of Clear() is
provided by the trait rather than the underlying object, and that the
ability to do this is what distinguishes a trait from an interface. I don't
think that's right.
Aside: I don't see how this adds methods to the underlying type. It merely
adds methods to the trait. Which seems perfectly OK, because a trait
definition is really just a class definition. What am I missing?
Meanwhile, going back to the original Traits paper, I don't think this is
what traits do. In the original traits paper, two key statements are made:
1. Traits may not define state
2. Class = Superclass + State + Traits + Glue
In effect, what seems to be going on is a two-tier inheritance system. You
can inherit state and methods from your superclass, which is normal single
inheritance. You can additionally inherit from traits in the style of
multiple inheritance, but because traits cannot introduce or consume state,
the problems of diamond-pattern multiple inheritance are eliminated (or at
least reduced). So I think that a Trait is a specially constrained type of
class that, by virtue of those constraints, can be safely multiply
inherited without breaking composability.
My objection to the method implementation within Ben's class ICollection
above isn't that the method implementation exists. It is that the type and
the implementation are mixed. My preference would be that the Interface
declaration should declare a [set of] method type[s], and there should
separately be Interface instances - this in exactly the way that there are
type classes and type class instances. Having a *default* method
implementation written in the type declaration as a labor saving mechanism
seems fine. Having a *required* method implementation not so much.
There are a couple of reasons that I want things this way:
1. As with type classes, this allows interfaces to be implemented after
the fact by third parties.
2. Those interface implementations might overlap, in the same way that
TC instances can overlap.
3. It allows an object to implement multiple variants of an Interface.
E.g. two ordering interfaces returned, respectively, by Increasing() and
Decreasing().
The question then becomes: what interface is obtained by default when we
see the expression "x as SomeInterface". It seems to me that this is
exactly equivalent to choosing the appropriate TC instance in the presence
of overlapping TC instances; a problem that we have already wrestled with
and more or less solved.
Thoughts?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
