typed objects and value types
C. Scott Ananian
ecmascript at cscott.net
Thu Apr 3 05:57:39 PDT 2014
On Thu, Apr 3, 2014 at 3:00 AM, Dmitry Lomov <dslomov at chromium.org> wrote:
> On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg <rossberg at google.com>
>> > A uvalue is deeply uvalue only when its prototype and all the methods
>> > found
>> > there are uvalues. Although this is the case for E, the implications for
>> > JS
>> > are, ahem, tricky. If they're not deep in this way, then they can't be
>> > passed transparently between vats, address spaces, and machines.
>> How can a prototype possibly be a fully structural value in
>> making all functions objects with identity?
>> On the other hand, I also don't see how uvalues can work without a
>> prototype link. So it seems that it's simply impossible to make them
>> transparently transferable between vats in the way you desire (and I
> Correct, yes - I think Mark says the same thing when he says "the
> implications are tricky".
> "Passing transparently between vats, address spaces, and machines" must be a
> non-goal for value objects as proposed.
> That's also how I read "uvalues have a prototype ... when transmitted
> between realms, uvalues retain this link" - among other things, it means
> that uvalues from different realms are never equal (since their prototype
> links are different by virtue of belonging to different realms).
You can never compare uvalues from different realms: both uvalues need
to be in the same realm before you can do the comparison. All you
need is that equal uvalues in realm A become equal uvalues in realm B
when passed over. This is exactly how existing primitives work,
More information about the es-discuss