Le 3 juil. 2014 18:32, "Jonathan S. Shapiro" <[email protected]> a écrit :
> > Ironically, I used to take the view that the object was the state, and there > might be many organizations of behavior acting on that state. If I may be excused for popping back up after all this time... 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? Where all interface types are fully foreign to each other, inheritance being but a trick to save typing and make programming palatable to disciples of Plato... Why should upcast / downcast look and feel any different from any other method that happens to return an object? (I already had a hard time swallowing the exact same debate over constructors, although I do see the point now) 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... But then again maybe I should read the 4+ posts that popped up while I was making up my mind about mine... -- Dominique Quatravaux [email protected] _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
