On 12/6/13 11:56 AM, David Bruant wrote:
If one can obtain two references to the same object, but with a
different contract then the interaction isn't that mediated. On the
party with the 2 references is enforced the disjonction of the
contract while the intent seems like the conjunction would be more
appropriate.
In any case, in which conditions can one end up with the same object
with two different contracts? Especially if the two contracts are
different, it looks like one contract could be violated (if the second
contract more relaxed) which sounds going against the developer intent.
Suppose you have an output manager object that implements a Logger
interface and a FileHandler interface.
If you have a function, worker, that accepts two arguments, a logger and
a fileHandler, then you could pass the same output manager object to
your function in two different roles.
var oman = new OutputManager();
var g = applyContract( "(Logger, FileHandler) -> Any", worker );
g (oman, oman);
This application should be fine because oman implements both roles.
In the body of worker(logger, fileHandler), logger is a Logger and
fileHandler is a FileHandler, so the two contracts do not interact.
However, if you use a join operator, as proposed by Mark, then the
resulting object
var logHandler = join(logger, fileHandler);
should be restricted to the intersection (= conjunction) of the two
roles, Logger&FileHandler (which is presumably empty in this example).
Relative to one party with 2 references to the "same" object with 2
different contracts, the interaction with each obejct is different.
Are the two references really to the same object, then?
Very good question. Please wind back in this thread as check out the
previous discussion on exactly this question.
My personal answer is that if worker is called with two references to
the same object, but in different roles / under different contracts,
then it should be that (logger === fileHandler) and this is also the
position that Racket takes. Others have different views on this subject.
-Peter
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
