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>
> wrote:
>> > 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
>> JavaScript? Especially, since the language has this great feature of
>> 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
>> would, too). It seems that JavaScript is actively hostile to that
>> idea.
> 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 mailing list