typed objects and value types

[Mark S. Miller]

On Wed, Apr 2, 2014 at 1:02 PM, Dmitry Lomov <dslomov at chromium.org> wrote:
>
> On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller <erights at google.com> wrote:
>
>> You can't recreate a given fat pointer out of thin air. You need at least
>> the same backing buffer, or something (e.g., another fat pointer) which
>> retains the same backing buffer.
>>
>> The backing buffer has generative identity, so the WeakMap should hold on
>> to the backing buffer weakly[1], but it should use the entire fat pointer
>> to compare for key equality.
>>
>> [1] In the normal ephemeron sense of "weakly".
>>
>>
>> Note that I am only pointing out that all this is possible, and is the
>> least surprising extension of the semantics of the various objects
>> involved. If implementors say this isn't worth it and would rather just
>> reject typed objects as keys, I'm ok with that, as long as we all agree
>> to reject.
>>
>
> Point taken, yes, there are conditions that ensure that this typed object
> can never be recreated, but I am not sure this will in practice be the
> least surprising extension (from the practical point of view of "why my
> WeakMap still holds on to these values? Oh it is because there is this one
> typed object that shares the buffer with all these other objects"). From
> practical standpoint, it feels like once we have made GC observable
> (through WeakMaps), we just can't have objects (weak map keys) with
> non-generative identity.
>
> So as an implementor, I feel that we should reject typed objects as weak
> map keys.
>

Reiterating, I am fine with this conclusion. I even buy the perspective in
which this is less surprising than my proposal.

However, I have to quibble with "observable". WeakRefs make GC observable.
WeakMaps do not. Running out of memory, or failing to, is not an
observation, since the spec never says when this might or might not occur
anyway. In fact, the spec as written is only faithfully implementable on a
machine with an unbounded amount of memory ;). (I regret the missed
opportunity to discuss test262 and infinite machines on April 1)


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140402/47dfd6ec/attachment.html>