Brandon Benvie wrote:
For value objects, I think it would be problematic if `1m +
iframeEval('1m')` or `1m === iframeEval('1m')` didn't work. It would
also be a shame if my user-overloaded `new Point(0, 0) +
iframeEval('[5, 5]')` didn't work.
Really? How often does cross-frame application arise (never mind
application of operator-proxy functions)?
Potential solution for builtin value objects: all realms actually
shared the same value object constructor and prototype and these are
deeply frozen from a null realm to prohibit side channels.
Potential solution for user defined operator overloading:
`defineOperator` could also take a string for any of the builtin
classes that allowed it to work cross realm:
defineOperator('+', addPointAndArray, Point, 'Array')
Bonus points if it works with a class extending any realm's builtin,
like `class MyArray extends iframeEval('Array') {}`.
Sorry, but I don't think this works (I considered it). What is the locus
of sharing? Same origin (say we define origin as a property of realm and
equate all realms with same origin). Still not right: disjoint
window/frame-graphs should not share. Ok, use the now-standard
ancestor-based algorithm: still wrong in cases of windows that cooperate
loosely and not in all operator overloadings.
You can't have your cake and eat it: either value objects are
extensible, in which case realm matters; or they're not extensible,
period full stop.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
