The problem is that member functions *aren't* just syntactic sugar on type class methods. Member functions have access to private/protected fields and members; type class methods do not (unless the implementing function is a member function).
On Wed, Feb 9, 2011 at 8:11 AM, Sandro Magi <[email protected]>wrote: > On 2011-02-09 4:43 AM, Jonathan S. Shapiro wrote: > > Yes. If we adopt this view, then type class methods and member functions > > have a sensible reconciliation. > > > > But the question will then arise (in the mind of the developer): when do > > I use member functions and when do I use type class methods? It becomes > > a challenge of design, and not one that is easily resolved. My guess is > > that /most/ developers will choose methods, if only because they are > > familiar... > > I don't follow. Methods and type classes are the same in this view, so > they are just choosing type classes. Or are you suggesting that "member > functions" are syntactic sugar that desugars into type classes? > > I don't see any advantage to this view. It seems sensible to simply > choose the single, more general abstraction mechanism and stick with it, > even if it's a little unfamiliar to developers. > > Sandro >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
