On Sun, Jan 5, 2014 at 3:53 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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? > It doesnt add it to the underlying type but you can call it when your working on the class typed as the trait. And you can stack traits , so these methods replace the virtual methods of inheritance. Remember the definition of a trait ( from memory) is a number of methods the type must implement AND a collection of methods. A better example from Scala how it looks from the user trait Similarity { def isSimilar(x: Any): Boolean def isNotSimilar(x: Any): Boolean = !isSimilar(x) } > 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. > There is no state except the normal interface wrapper ( eg this) . Note the code above is not how a user impliments an interface or trait but how it looks in the runtime t. I missed the definition should include interface methods for Clear and Remove. > > 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? > Agree but Im against even a default implimentation hence interfaces not traits. - The time saving is trivial compared to injecting a common implementation ( especially with a lambda expression/ delegate) - You introduce a lesser form of the Fragile Base class problem , a lot of consumers can use the same code and have uninteded consequences when you change it especially for more than 1 client. You maybe able to overide the default but you may need 2 common implimentations do you create 2 type classes , 2 methods or go back to injecting the common implimentation ? Now if you had a seperate common implemenation already the same change is trivial you dont need to think much . Copy it change what you want and inject the new code into the classes that need it .. - The fact an interface is a contract is a solid concept . Once you add code you loose that. - An environment C# and Java people are familiar with . Type class already add confusion. Sure you can say traits are like interfaces but once people see code there it will be confusing. By having interfaces you have a way people can enter the language do something they are familiar , be productive while they learn the rest. - Testing. The shared method may not be relevant to a test and is difficult for the test to override it. Basically fragile base class. So basically KISS its not worth the very small benefit and some people will do bad things with it. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
