Private Slots

David Bruant bruant.d at
Tue Jan 15 12:30:23 PST 2013

Le 15/01/2013 21:06, Herby Vojčík a écrit :
> David Bruant wrote:
>>> ES6 provides WeakMaps and Proxies. Why not see what people do with
>>> those before introducing private slots?
>> I wouldn't be opposed to that, but that's just my opinion. Still,
>> private symbols allow property-like syntax. I haven't followed the
> Hm. If this would be the best benefit (and putting aside the issue of 
> WeakMap GC cost for a moment), one may think about "property-like 
> access, but with reversed responsibilities" which could allow for 
> easing things like that. For example, if I abused @ character for that 
> (as a replacement for .), I could write:
> at baz.quux
> to mean
>   baz[].quux // reversed access, ie WeakMap
> and
> at baz(quux)
> to mean
>   baz(, quux) // more functional OO-like
> (not necessarily the same syntax, just the idea, that, instead of 
> private slots, one can provide "reversal" into the language allowing 
> to use certain pattern easier)
I agree there is an equivalent between private symbols and weakmap. Both 
are a (object, object) -> value mapping (symbols can be getters, etc, 
but it could be implemented with weakmaps too)

In theory, private symbols should have the same GC issues than WeakMap. 

     var o = {}, o2 = {};
     for(var i=0, i<1000, i++){
         let s = new Symbol(true /*private*/);
         o[s] = o2[s] = i;

Here, private symbols are created, properties are added. Because of 
let-locality, every symbol can be GC'ed, because at the end of the loop, 
no one can ever access any of the symbols. The equivalent of the WeakMap 
GC property would want properties in o and o2 to be removed too. I'm 
willing to bet this will never happen in any JS engine.

The major difference is how people will use each tool. From experience 
in OO programming, most objects have a finite set of properties 
determined at object creation time. It's true even in JavaScript where 
objects are bags of properties. This allows to write "stable" code (you 
can write "o.find()" assuming there is a find property which value is an 
function). If people were creating eratic objects, writing what I call 
"stable" code would be a much more complicated exercise. This "cultural" 
use of objects is what makes optimizations like Shape/HiddenClass possible.
WeakMaps, on the other hand, are used as a maps key'ed on objects, with 
the convenience that you don't need to clean the map when the object is 
about to disappear. There is a assumption that when you create a new 
weakmap, its use is largely independent of previous weakmaps and it's 
unlikely 2 weakmaps will have the same set of objects, so engines are 
unlikely to perform optimizations combining different weakmap storages 
so that the values of the same key will be close to one another or 
something like that.

WeakMap and Symbols each corresponding to a given patterns of use of 
(object, object) -> value mappings. Although a unique feature could be 
used to emulate the other, it would be very hard for an implementation 
to optimize one feature for 2 patterns.
If anything, choosing one feature over the other is a way to tell your 
coworkers and the JS engine which pattern you want to use.


More information about the es-discuss mailing list