On 7/29/2013 4:04 PM, Brendan Eich wrote:
Regarding realm associations? What is the rationale for making the
typeof binding per realm? I would expect the people would want (at
least operator associated) value object instances to be freely used
across realms, just like numbers, strings, and booleans are.
Why would you expect methods attached to prototypes to be cross-realm?
They wouldn't be even for double-dispatch, in this sense: you would
not know which "@@ADD" or (Python) "__add__" you were calling across a
realm. In an OOP sense this works, but for dyadic operators as
Chambers, et al. argue, it's wrong. The multimethod approach fits the
problem precisely, but only same-realm or (if cross-realm) only if you
load the same value object extension in both realms.
All methods have realm dependencies. If you are assuming built-in
status means string primitives get the same indexOf, e.g., even that
can be monkeypatched to diverge cross-realm.
And I don't think you have mentioned anything about defineOperator
creating realm specific operator bindings.
You missed the point Luke made at the meeting: see the v + u operator
semantics slide, where p intersect q is based on function object
indentity, and functions are realm-specific without extra work (e.g.,
loading a value object extension once in an iframe and ensuring all
instances come from that iframe -- artificial, contrived!).
So, I would expect that in:
x + 1
the value of x may be (for example) a decimal number defined in a
different realm and that the + gets appropriately dispatched to do a
Decimal+Number add operation.
Which one, though? However the dispatch works, methods on prototypes
are per-realm.
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.
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') {}`.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
