typed objects and value types
dslomov at chromium.org
Thu Apr 3 00:00:25 PDT 2014
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg <rossberg at google.com>wrote:
> On 2 April 2014 20:26, Mark S. Miller <erights at google.com> wrote:
> > We could specify that WeakMaps can use typed objects as keys. The current
> > discussion in your article confuses semantics with implementation when it
> > speaks of typed objects comparing structurally. Typed objects have
> > characterized by the four-tuple you explain. Just as all the bits of a
> > pointer are significant when comparing two thin pointers to see if they
> > point at the same semantic object identity, so are all the bits in your
> > pointer significant. Don't get confused by the bits in the pointer to the
> > fat pointer, when the fat pointer happens to be boxed.
> I'm not sure I agree with your notion of identity on pointers here. It
> doesn't make sense to me, semantically, to characterise structural
> (fat) pointers as having identity, just because their pointees have.
> (Or in other words, tuples do not acquire identity just because some
> of their components are values with identity. This is mixing up
> In any case, from the low-level perspective of the GC, a fat pointer
> definitely is an object separate from the buffer it points to (though
> it strongly references this buffer). Weak maps currently work by
> making the references to their keys weak. But that would simply be
> incorrect in the case where a key is a fat pointer -- because of its
> structural equality, an equivalent pointer can be recreated. It is
> unclear to me how weak maps could (efficiently) be extended to support
> this particular notion of reverse transitive weakness that you allude
They can, in theory - for the sake of argument, let's define "weak
reference to fat pointer" to be "weak reference to its backing store +
offset" (this is probably even fairly efficiently implementable). The
question is, is this a desired semantics, and as we discussed above, it is
"True JS object" with generative identity seems to be a nice demarcation
line for any notion of weak reference that we have (admittedly, we do not
have the notion of weak reference per se in the spec, only weak maps, but
willy-nilly the programmers will reason of them in terms of weak
> >> - uvalues have a prototype linked to their def'n
> >> - the syntax 'uvalue.foo' can be used to access members of this
> >> prototype
> > +1.
> >> - when transmitted between realms, uvalues retain this link
> > A uvalue is deeply uvalue only when its prototype and all the methods
> > there are uvalues. Although this is the case for E, the implications for
> > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss