<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/20/2015 5:55 AM, Bert Freudenberg
wrote:<br>
</div>
<blockquote
cite="mid:FC7E40CD-9EE1-4540-A8E3-F5498C7E525C@freudenbergs.de"
type="cite">
<pre wrap="">On 20.01.2015, at 08:25, Florin Mateoc <a class="moz-txt-link-rfc2396E" href="mailto:florin.mateoc@gmail.com"><florin.mateoc@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 1/19/2015 1:03 PM, Florin Mateoc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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 :) )
</pre>
</blockquote>
<pre wrap="">
Yep. Working around the lack of weak collections in JavaScript was why I had to come up with my own memory model. I couldn't simply adopt Dan's, who used a Java weak array in JSqueak/Potato.
I briefly got excited about the new WeakMap support in ES6, but as you discovered, without enumeration they are much weaker (pun intended) than what we have in Smalltalk. At first I thought they were completely useless, since the same could be achieved by adding a property to each object. But beyond that you can bulk-empty the WeakMap, being equivalent to removing that property from all those objects. So essentially WeakMaps are useful as caches that can easily be invalidated. I cannot think of another application.
</pre>
</blockquote>
<br>
Well, they also work as an "alreadySeen" collection for recursive
operations.<br>
<br>
<blockquote
cite="mid:FC7E40CD-9EE1-4540-A8E3-F5498C7E525C@freudenbergs.de"
type="cite">
<pre wrap="">
The *reason* for designing WeakMaps in such a limited way is that the ECMAScript committee thinks garbage collection should be unobservable. No expression in the language should depend on the state of the GC. This gives implementers of the language a lot more freedom in designing their VM.
</pre>
</blockquote>
<br>
I am not sure I understand this argument. Indeed, as they say,
enumerating weak collections introduce some indeterminism. So what?
Does that make Smalltalk or Java programs in general less
deterministic than JavaScript ones? Obviously one has to take care
and work around the possibility that something might or might not be
there, but this is not such a unique situation in programming. As
for the vm implementors, I wouldn't know, but did actually
implementing weak references make the vms (various Smalltalk, Java,
ActionScript...) take a hit in general performance or complexity?<br>
<br>
I think they only thing they "really" cared about was something
about security (this is Mark Miller we are talking about :) ):<br>
"<span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue',
Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: 19.5px; orphans: auto; text-align: left; text-indent:
0px; text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
!important; float: none; background-color: rgb(255, 249, 227);">This
is necessary to prevent attackers observing the internal behavior
of other systems in the environment which share weakly-mapped
objects. Should the number or names of items in the collection be
discoverable from the API, even if the values aren't, WeakMap
instances might create a side channel where one was previously not
available."</span><br>
<br>
And I don't think this argument holds water, especially since, as I
said, they could have offered both secure and unsecure versions.<br>
<br>
Florin<br>
</body>
</html>