typed objects and value types

[Mark S. Miller]

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.



On Wed, Apr 2, 2014 at 12:25 PM, Dmitry Lomov <dslomov at chromium.org> wrote:

>
>
>
> On Wed, Apr 2, 2014 at 9:11 PM, Dmitry Lomov <dslomov at chromium.org> wrote:
>
>>
>>
>>
>> On Wed, Apr 2, 2014 at 8:26 PM, 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
>>> 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.
>>>
>>
>> It is unclear to me how WeakMaps can ever use typed objects as keys,
>> since typed objects do not have their unique identity. Or rather, the only
>> possible semantics I see is "hold to the value forever". So for example:
>>
>>    w = new WeakMap();
>>    w[Point(buffer, 0)] = "abc"; // 1
>>
>>    w[Point(buffer,0)] = ? // 2
>>
>> I believe that in line 2, result should always be "abc" (since
>> Point(buffer, 0) === Point(buffer, 0)).
>> This is something we can spec, but it is probably not behavior we want.
>>
>
> (to put it another way, for "normal" objects/thin pointers, the user
> cannot construct the new identical thin pointer out of thin air, therefore
> garbage collection is possible; whereas the typed objects/fat pointers are
> user-reconstructable at any point of time - so garbage collection is
> impossible).
>
>>
>> Dmitry
>>
>
>


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