On Sun, Jul 28, 2013 at 8:22 AM, William ML Leslie < [email protected]> wrote:
> Ack. You were talking about module boundaries, which is not what I > was talking about at all. I clearly no longer function at 1 AM. > Correct, we are talking about resolving ordR across module boundaries after run-time late-binding. "Most languages" with this interface concept require interfaces implementations to be defined in the object implementation. Once we allow orphaned instances of the interface to be defined outside the object and apply to the object after-the-fact, we run into a collision problem where there can be more than one instance of an interface. (more than one implementation trait OrdR) In this situation, we need a clear mechanism for sortR to decide which OrdR implementation to use, because object-instance->ord-trait is insufficient to decide between them. Here are some options sortR can use: a) allow/require allocators of R to bind in a single-specific OrdR to the instance. (this limits a module's ability to add behavior to existing instances.. it also admits a collision if the author of R ever adds his own OrdR) b) resolve at load-time of the sortR module by the controller of this run-time bind... However, this can still run into collisions, as two different modules can import sortR and expect to control the ordR implementation separately c) use a fast-stack-walk to determine the caller, and the caller's preference for ordR ... this has cost, and could run into ordR coherence problems if data passed in escapes and later needs OrdR d) make the OrdR an expliclt paramater of the sortR function. (which I suggested could happen implicitly once OrdR is a mixin-interface) This could also run into ordR coherence like "c" ... are there other means?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
