> > > Yeah, I understand why some people try to think of this as subtyping. It > isn't. Interface contracts aren't subtyping. >
Yes thats wrong and i did actually know that .. I need to be clear but im of muddle mind. > > 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. >> > > Actually, the paper says nothing about requiring an interface wrapper! > True but how else do you implement the methods that must be defined for a type that impliments it . You could do it without polymorphism but it woulnt be very nice. . > > >> Agree but Im against even a default implimentation hence interfaces not >> traits. >> > > I can see the purist view on this, but they are too useful pragmatically > to give up. As a dumb example, odd = !even. Why make every instance > replicate that unnecessarily? > > But yeah, it can be abused. > In the case of few instances ( most ineterfaces have only a single object its no saving , for a large amount you simply add the common implimentations as a new class or a shared delegate. The time saving is too minor. > > >> - The time saving is trivial compared to injecting a common >> implementation ( especially with a lambda expression/ delegate) >> > > Not so. This is *where* you inject the common implementation! > Disagree. Its nice but the pain in maintenance issues do not out weight the time save. > > >> - 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 .. >> > > Good points. If you can't cover those problems with overlapping instances, > then there wasn't a common enough implementation in the first place. > It will push people to find a common implimentation where there is only a poor one none thats part of the issue . > > But as a counter-example, there are lots of collections where you want to > store and manage scalars differently from reference types. Yet the majority > of collections contain objects of reference type, and why implement those > lots of times? > You dont need many you have a common ReferenceCollectionImpl and ScalarCollectionImpl. Which each type uses as needbe. To me this is what type classes are better at with the interface being an encapsulating wrapper if its needed. > Though that's an example where overlapping instances is the right way to > go. > > > >> So basically KISS its not worth the very small benefit and some people >> will do bad things with it. >> > > So oddly enough, I agree with you, and I'd be willing to push the > overlapping instances thing first. > > The one exception is closed type classes/traits, where the implementation > and the TC/trait need to be lexically together. > I dont see how this is an issue . You can put the impl and the TC in a seperate scope or module. Normally you only have impl. seperate when you have your second type that needs it . So you pull out the code from the first type and create a new type. Note one huge diff with Java / C# is we are using interfaces as our encapsulation ( for objects that are visable outside the module) , this is a good thing but means creating more interfaces than normal . Normally you dont create the interfaces unless there is a clear need for a contract eg when you have a 2nd class with the same behaviour you want to use where previously you only used the first. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
