Encapsulation is orthogonal to overloading. Haskell supports
encapsulation and type classes without requiring the introduction of
member functions. Member functions are then simply the composition of
type classes and some means of encapsulation, like existentials.
Unless I've misunderstood something, member functions look like a single
mechanism attempting to address two orthogonal concerns. You will then
support member functions, type classes, and functions, with little
fundamental difference between them.
If you multiply the abstractions, you will invariably force library
writers to multiply the number of implementations they need to provide.
See for instance, Haskell's sort/sortBy and the numerous other overloads
required because Haskell, a) doesn't support named instances, and b)
doesn't have an easy transition between functions and vtables like they
could with, say, first-class type classes, or named instances + using
type classes for first class functions too, ie.:
val old_map: ['a] -> ('a -> 'b) -> ['b]
val new_map: Map 'a 'b => ['a] -> ['b]
Sandro
On 2011-02-10 4:24 PM, Jonathan S. Shapiro wrote:
> 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]
> <mailto:[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
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
