On 7/30/2013 9:39 AM, Brendan Eich wrote:
Brendan Eich wrote:
I just mean an instance of a Map or a class that extends Map.
Essentially all I'm saying is that you match by [[Class]] (which
doesn't exist in ES6, but a heuristic to determine what is
essentially [[Class]] does exist).
defineOperator('+', addPointAndArray, Point, Array) // matches
only this realm's Arrays
defineOperator('+', addPointAndArray, Point, 'Array') // matches
any realm's Arrays, [[Class]]
Basically, if `Array.isArray(rhs)` is true, I'd want it to match
`'Array'` in operator overloading.
I got that, it's a nice API -- but it requires us to define
world-of-realms-that-can-share-references, no?
Say we define a world as set of reachable realms. Both the HTML
processing model and DOM API calls can extend the world. When that
happens for new realm R with global G, given the
defineOperator('+', addPointAndArray, Point, 'Array') // matches any
realm's Arrays, [[Class]]
call, an observer watching for new realms would
defineOperator('+', addPointAndArray, Point, G.Array)
The Point.prototype.@@ADD array (hmm, should be a Set -- array was
from a pre-ES6-Set state of play) already has an element with value
addPointAndArray due to the first call, so this call would find that
element, and then only add addPointAndArray to
G.Array.prototype.@@ADD_R's array.
Then code evaluated in R that uses Point (the shared singleton) and
G.Array (say via an array literal -- arrays are not value objects but
let's skip that!) can use +.
This could be made to work. Is it the right design? It leaves Point as
a world-shared singleton, while using each realm's 'Array'.
Point.prototype.@@ADD and other sets grow quite large (not a problem
if we use Set, O(1) lookup). There's a shared mutable Point,
Point.prototype, Point.prototype.* channel, world-wide.
As noted, operators-via-methods creates realm-dependency. But if we
add worlds of realms, we could distinguish world-globals and load
things once, where the sharing is wanted. Unwanted sharing is still a
hazard and some realms will want their own unshared value objects and
operator methods
That design seems to fit the behavior I was thinking, but I was
envisioning something more along the lines of an alteration to the
algorithm:
For the expression v + u
* Let p = a new List
* Let pOverloads = v.[[Get]](@@ADD)
* If pOverloads is not undefined
* If pOverloads is not a Set throw a TypeError
* Else append the values of pOverloads to p
* If v has a [[SharedOverloads]] internal property
* Let pSharedOverloads = v.[[SharedOverloads]](@@ADD)
* Append pSharedOverloads to p
* If p has no items throw a TypeError
* Let q = a new List
* Let qOverloads = u.[[Get]](@@ADD_R)
* If qOverloads is not undefined
* If qOverloads is not a Set throw a TypeError
* Else append the values of qOverloads to q
* If u has a [[SharedOverloads]] internal property
* Let qSharedOverloads = u.[[SharedOverloads]](@@ADD_R)
* Append qSharedOverloads to q
* If q has no items throw a TypeError
* Let r = p intersect q
* If r.length != 1 throw a TypeError
* Let f = r[0]; if f is not a function, throw
* Evaluate f(v, u) and return the result
[[SharedOverloads]] would return a cross-realm list such that
`realmA.int64.[[SharedOverloads]](@ADD) ===
realmB.int64.[[SharedOverloads]](@ADD)`.
Using a string in addOperator for one of the types checks the string
against the list of builtins that have [[SharedOverloads]] and adds it
to that list.
I fully admit that this may be overkill to support an edge case, and as
I said I don't even know if it's expected for multi-realm usage to happen.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
