On Sat, Jan 4, 2014 at 8:57 PM, Ben Kloosterman <[email protected]> wrote:
> > > > On Sun, Jan 5, 2014 at 3:53 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> 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. > This whole notion of "a class typed as a trait" gives me the screaming heebee jeebies. I understand why people want to think of this as a subtype relationship, but I really don't think that it is. When you execute the expression: ob *as* SomeInterface in Java, the object reference you get back does not point to the same state that *ob* points to. It's a different object with a different type. There is no subtyping relationship involved. Similarly for ob *as* SomeTrait Yeah, I understand why some people try to think of this as subtyping. It isn't. Interface contracts aren't subtyping. 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! > 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. > - 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! > - 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. 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? 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
