On Sat, Jan 4, 2014 at 5:57 PM, Ben Kloosterman <[email protected]> wrote:
> In most cases interfaces will stll be slower when you use them in a > polymorphic manner. > That's a whole lot less clear than you might think. A responder on LtU pointed out that TCs provide compile-time polymorphism where interfaces provide runtime polymorphism. That much is clearly true, and I think you're assumption about performance is being driven by that. But the reality is weirder than that, because BitC doesn't have virtual functions. Here's why that matters: While interfaces encapsulate existentially, there are many many cases where the underlying existential type variable is externally known. When we see: ObType ob; ... ob *as* SomeInterface we can type the result as (making up notation on the fly): SomeInterface *on ObType* The "on ObType" part is additional information that we are free to forget at any moment. But wherever we still *have* this information, we are free to do compile-time specialization in exactly the way that we would for type class instances. And of course, if we have a JIT system, we can do polymorphic inline caching for this. And finally, code explosion isn't free, and one of the dark consequences of type classes over unboxed types (or, indeed, boxed types) is that they induce code explosion of epic proportions, in much the way that C++ templates do. Unlike C++ templates, we can't exploit our ability to break the type system to produce common implementations of the common cases. If prototyping or writing smaller single exe apps than you may as well just > use type classes. > Good thought. How should this thought be guiding me as a *library* author? What I'm really asking is: what assumptions should a general library author be adopting? > If you care about security / POLA you will prefer interfaces. > I'm not clear here why one is better than the other. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
