Weak{Map,Set}.p.clear() implementation proposal
Nice idea, but there seems to be (some) complications.
Set this to T.
What is this specifically? As far as I can see, it is a value and not a
reference. And even if it were a reference, setting it to point to another
object does not affect the other references which point to the old WeakSet.
What I mean is, consider this code:
var wsRef = new WeakSet();
var wsRef2 = wsRef;
wsRef.clear();
As far as I can see, in the wsRef.clear() algorithm, the this value has
no relation with the wsRef identifier. Even if there was some internal
magic around changing the identifier's reference, there would still be
other references pointing to the old WeakSet object. So your proposal seems
to require replacing an object in the memory with another while keeping the
references intact, which (I believe) does not exist in ECMAScript.
I may be wrong though, let's other for someone with more experience to have
a say on this. =]
On Oct 28, 2014 10:18 PM, "Fabrício Matté" <ultcombo at gmail.com> wrote:
What I mean is, consider this code:
var wsRef = new WeakSet(); var wsRef2 = wsRef; wsRef.clear();As far as I can see, in the
wsRef.clear()algorithm, thethisvalue
has no relation with the wsRef identifier. Even if there was some
internal magic around changing the identifier's reference, there would
still be other references pointing to the old WeakSet object. So your
proposal seems to require replacing an object in the memory with another
while keeping the references intact, which (I believe) does not exist in
ECMAScript.
I may be wrong though, let's other for someone with more experience than
me to have a say. =]
Not in pure ECMAScript being interpreted, but it can definitely be done in the implementation. On Oct 28, 2014 10:18 PM, "Fabrício Matté" <ultcombo at gmail.com> wrote:
What I mean is, consider this code:
var wsRef = new WeakSet(); var wsRef2 = wsRef; wsRef.clear();As far as I can see, in the
wsRef.clear()algorithm, thethisvalue
has no relation with the wsRef identifier. Even if there was some
internal magic around changing the identifier's reference, there would
still be other references pointing to the old WeakSet object. So your
proposal seems to require replacing an object in the memory with another
while keeping the references intact, which (I believe) does not exist in
ECMAScript.
I may be wrong though, let's other for someone with more experience than
me to have a say. =]
You can't in plain ECMAScript interpreted, but you definitely can in the implementation backend.
My client needs to not glitch on me... :(
Not in pure ECMAScript being interpreted, but it can definitely be done
in the implementation.
Yeah I think so too, but if no where else in the specification uses this pattern, implementations would be required to implement new mechanisms and possibly have de-optimizations.
Actually, the de-opts shouldn't exist, considering it's effective equivalent in C++ would be pretty straightforward (and could be polyfilled in Node literally via native code):
Handle<JSWeakMap>* createClearedInstance() {
// ...
}
// ...
Handle<JSWeakMap>* wm->inst = createClearedInstance();
Looks nice, then. ;) Though, this may not be so easy to implement in
other languages which don't provide direct access to memory addresses,
affecting implementations such as Rhino which is written in Java.
Also worth noting that as this can't be implemented in pure ECMAScript, polyfilling is impossible. Though, the whole Weak* semantics are very hard to implement in pure ECMAScript anyway.
On Tue, Oct 28, 2014 at 10:58 PM, Fabrício Matté <ultcombo at gmail.com> wrote:
Looks nice, then.
;)Though, this may not be so easy to implement in other languages which don't provide direct access to memory addresses, affecting implementations such as Rhino which is written in Java.
Nit: Object properties in Java are passed by reference, not value. Method behavior is similar. It would still be possible in this case.
I'm bumping the initial link: impinball/weakmap
I understand that objects are passed by reference in Java (similarly to ECMAScript), however I'm not sure how implementations link Lexical Environments' identifiers to their respective values, and re-mapping these would be more complicated than the C++ sample you've posted I believe.
As far as I can see, this seems a lot more complicated than it is worth, and it would at least require a new abstract operation for internally in-place replacing objects while keeping references intact.
Wouldn't it be far easier to just have an internal data property in each Weak(Map|Set) which can be replaced by a new list/object? Then implementations can just access/pass-by-reference the Weak(Set|Map) object and methods can read its data property. In fact, that seems to be what the spec already does:
[23.3.3.1 WeakMap.prototype.clear ( )](
people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.clear )
... 5. Set the value of M’s [[WeakMapData]] internal slot to a new empty List.
And
[23.4.3.2 WeakSet.prototype.clear ( )](
people.mozilla.org/~jorendorff/es6-draft.html#sec-weakset.prototype.clear )
... 5. Set the value of S’s [[WeakSetData]] internal slot to a new empty List.
How would your proposal simplify those algorithms?
On 29 October 2014 02:48, Isiah Meadows <impinball at gmail.com> wrote:
I'm proposing simply initializing a new instance and GC'ing the old instance entirely (updating the
thisto point to the new) instead of the current algorithm of maintaining a list of keys. I know that it potentially slow down the method itself, but it could eliminate the need for keeping a Map-like index of keys.
That makes no sense. I neither understand what this is supposed to achieve, nor how it could possibly be implemented other than by going over the entire heap and replace all pointers. You cannot just "set 'this' to point to new map".
It doesn't seem to intend changing the semantics either, so even if it made sense, would be entirely irrelevant for the spec.
I'm proposing simply initializing a new instance and GC'ing the old instance entirely (updating the
thisto point to the new) instead of the current algorithm of maintaining a list of keys. I know that it potentially slow down the method itself, but it could eliminate the need for keeping a Map-like index of keys.I know that this is kinda on the late side for such drastic internal spec changes, but might fix the problem of indexing WeakMap and WeakSet entries
Link to formal proposal: impinball/weakmap