On Mon, Apr 9, 2012 at 10:53 AM, Geoffrey Irving <[email protected]> wrote:
> Moreover, the structure of A should be such that B can be compiled by > looking at only a portion of the files of A. This basically mandates > the existence of header files. The conclusion seems to be that you either need header files, or you > need to abandon the notion that upstream libraries can be recompiled > without recompiling downstream code. Is this a correct > characterization of the situation? No this is not a correct characterization. If only it were that simple. This problem space is not about header files. This is about the unknowability of runtime field-offsets in a subtype capable system with module upgradability. It's the C++ fragile-base-class problem, plus a bunch more. C-shared-libraries allow us to manually manage upgradability because of (a) the non-existing of subtyping, and (b) run-time linking is performed on named symbols in the shared libraries. C++ (and pretty much everyone else except MSIL) fails to provide a model for forward upgradability of separatly compiled modules. Put in specific C++ terms. If you make Class-A in module-A, then subclass it into class-AB in module B, then subclass it into class-ABC in module C, in C++ you are dead and you can't change module-A or module-B because any change to them (whether expressed in header files or not) shifts the offsets of all the instance data offsets for module-C. This is one narrow form of the fragile-base-class problem and no amount of "header files" will fix it. If you use our typical model for single-inheritence subtyping (subclasses) across module boundaries, then to achieve any form of forward upgradability, you must do runtime field resolution (either slowly, or through JIT). However, this is only the tip of the iceberg. The entire space of typing/subtyping/parametrics/garbage-collection/JIT is all deeply inter-related. It isn't a situation where you "pick your language features" then "design your modular compilation system", some of these features are actually making it difficult if not impossible to support modular forward compatible separate compilation units.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
