On Sat, Dec 28, 2013 at 3:55 PM, Jonathan S. Shapiro <[email protected]>wrote:
> > So given a notion of method type (as opposed to function type) and the > ability to express a has-field constraint, it turns out that type classes > subsume traits *up to* inheritance. Actually, type classes are strictly > more powerful than traits, because they are type relations. This means that > they can express *provides* and *requires* constraints across multiple > types simultaneously. Not sure if that's useful, but from a language design > perspective it's nice when one thing eliminates the need for another. In a > language with type classes and object methods, traits are just syntactic > sugar. > So if you have classes w obj methods what does traits really give us over just interfaces ? They give you "type methods" on the trait type ( which allows an ordered diamond pattern inheritance for better or worse) but in modern OO ( where performance is not super critical) this reuse is frowned on as its better handled by injecting a shared implimentation on constructing the object since this shared implimenation is far more flexible than language based implimentations. > > The missing piece here is that type classes are not types. Which raises > the question: well, why are Traits types then? The answer is that Traits > tacitly assume a 'this type, and the trait itself is effectively an > existential wrapper of that. But Bruno Oliveira's work suggests that type > classes can be viewed as types. And if nothing else we can certainly > recognize those type classes that are equivalent to traits. > Isnt it better to just have the typeclass that has a "this" as the sugar ? Isnt HasMethod ( not sure on HasField) really a constraint that implies 1) a type that has this and 2) has a method of that name . And isnt HasMethod and naming that almost equivalent to a single method interface ? Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
