On Tue, Dec 30, 2014 at 8:40 AM, Jonathan S. Shapiro <[email protected]> wrote:
> There is a Haskell restriction that TC instances must appear either (a) in > the compilation unit where the TC is defined or (b) in the compilation unit > where the type is defined. This is an <em>ad hoc</em> restriction, and it's > actually kind of ugly, but I agree that if we assume this restriction then > the type class pattern can mostly be done in C++, and that your parametric > instantiation approach is interesting. > While my scheme is not type-classes, my scheme does not require either restriction. The static-interface-mixin is explicitly bound when the type-parametric is specialized, so there can be a plurality of implementations located anywhere and a precise combo is selected during binding. It might also be practical for a mixin-binding to be implicitly added as a parametric of the class it appeared in, this establishing a "hierarchy" of overridable mixin binding. That said, in my scheme, the original author must plan for the mixin. There is no way to post-facto add a normal interface an existing class. AFAIK one appeal of Obj-C category extension and type-classes is to make this possible. However, this creates the potential for interface-implementation collision, and requires some means of disambiguating (like haskell's rules).
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
