On 1/19/2015 1:03 PM, Florin Mateoc wrote:
> The idea for become: goes something like this (I know that standard WeakMaps are not enumerable, but given that
> Google/Caja were apparently able to write a WeakMap shim without native support, I hope that code can be used as
> inspiration to give us enumerable ones - this would also address the more general requirement for weak
> collections/allInstances): assignments, as well as the at:put: and instvarAt:put: primitives, add (if not already
> there) to the right-hand side object a WeakMap property "owners". This happens only for non-primitive types. The keys
> are the owners and the values are the indexes within the owner where the owned object lives. If there is already a
> previous object within the owner at that index, the owner/index pair is removed from the previous object's owners. At
> become: time, we iterate the owners and do the replacement

And of course, if we did have enumerable WeakMaps, cleaning up of the previous owned object's owners does not need to
happen, we can just check if what the owner has at the index is still valid at the time of executing become: or
allReferences - this would move some pain to the right/less frequent place.

Unfortunately, the shim that I mentioned is a dead end - they just store, as a hidden property, each weakMap value in
the corresponding object used as its weakMap key, there is nothing stored in the weakMap itself to be iterated over.
I think it's a pity that, for some obscure security scenario, they (ECMAScript) cripple an otherwise very useful
feature. They could have offered a secure, non-enumerable version of weak collections in addition to an enumerable one
for situations where it does not matter. Oh well, back to the drawing board (or to Bert's object layout :) )

Florin