Subclassing inheritance is over-rated :-) I prefer type class constraints, this can function like extending an interface in Java.
I think interface inheritance has much nicer properties than implementation inheritance, and you can always use a Decorator pattern. Yes, you need a pointer to an object after closure conversion, and you need a vTable pointer, but in my experiments a vTable has much faster dispatch than if or case statements. I would put the vTable pointer in the object, so the object pointer is a plain pointer that can be in a register. Keean. On 25 Feb 2015 17:00, "Jonathan S. Shapiro" <[email protected]> wrote: > On Wed, Feb 25, 2015 at 8:22 AM, Keean Schupke <[email protected]> wrote: > >> By capsules you mean existential types? This is currently my preferred >> method for runtime polymorphism, implemented using virtual functions on the >> type-class. >> >> I would be interested to know the problems with this as I like it as a >> solution. >> > I'm referring specifically to the BitC v0 mechanism, which implements a > form of existential encapsulation. Conceptually, make-capsule arranges for > several lambdas to be closed over a common (shared) closure record. From an > implementation perspective it forms a (vTable reference, closureRecord > reference) pair. The result is an object having methods. The construction > mechanism doesn't really provide for subclassing or inheritance. > > The most obvious problem is that make-closure is an allocating operation, > and we need to be able to use existential encapsulation in some places > where allocation is not permitted. I suppose we could have it return an > unboxed pair. The next most obvious problem is that too much indirection is > required when a capsule method is called. The third obvious problem is that > *sometimes* you want a "translucent" existential, in the sense that you > want to be able to dynamically cast back to the original record type. > > > shap > > _______________________________________________ > 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
