On 3 April 2014 09:00, Dmitry Lomov <dslo...@chromium.org> wrote: > On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg <rossb...@google.com> > wrote: >> >> On 2 April 2014 20:26, Mark S. Miller <erig...@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 >> > identity, >> > characterized by the four-tuple you explain. Just as all the bits of a >> > thin >> > 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 >> > fat >> > 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 >> domains.) >> >> 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 >> to. > > 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 clearly not.
You'd have to unwrap the whole fat pointer, right? So it would be "weak reference to backing store + offset + opacity + weak reference to prototype or type descriptor + dimensions", or something like that. The fact that there are two weak references in there seems to be asking for trouble already. The entry would die if one of those references dies. But in any case, since I view fat pointers as just an instance of uvalues, I was considering the more general case of nested uvalues with references to a backing store at (potentially) arbitrary depth. But I see that Mark wasn't talking about that general case, so I suppose that wouldn't matter. > "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 > references). Obviously, I agree. Although an argument could be made to also allow symbols. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
