On Thu, Jul 3, 2014 at 11:20 AM, Dominique Quatravaux <[email protected]> wrote:
If I may be excused for popping back up after all this time... Only if you stick around. :-) > I'm having a hard time finding the upside of this idea. If the language > design makes it apparent that objects sometimes share bits but have > different behavior, how do we justify the additional disclosure either > at compile time (that two types are in a subtype relationship) or run > time (through quirks of the "eq" operator etc.), which are completely > avoidable in a world view à la Java? Well, first, I'm not actually taking a position on this issue yet. Second, the disclosure *isn't* avoidable in Java. And third, BitC is a language whose applications need (sometimes) to deal with state in a direct, hands-on way. > Why > should upcast / downcast look and feel any different from any other > method that happens to return an object? Because upcast and downcast are very different from "fetch some other interface object through this interface". They are simply different operations. Upcast is an erasure. Downcast returns an object that is EQ to the original object, so we have this philosophy problem. "fetch another interface" is just a procedure call like any other procedure call, excepting only that it may be important enough to warrant syntactic support. And note that I think the philosophy problem is just silliness; pragmatically it doesn't seem to matter how we define "object". Nobody seems to be getting confused in practice. Also because downcast performs no allocation, where "fetch an interface" does. In a language that is sensitive to which operations GC, that's an important distinction as well. I feel like the idea of sharing bits as a language feature has done > enough damage to the world already (it allowed C++-style single > inheritance to become entrenched), maybe it's time to start treating > the sharing of bits as an (arguably quite useful) data inlining > optimization? And as such, one where implementors should tread very > carefully... > That's an interesting position to explore, but I don't think it's a position we can take successfully in a systems-oriented language, where explicit sharing of state may be vital. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
