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:
foo....@baz.quux
to mean
baz[foo.bar].quux // reversed access, ie WeakMap
and
foo.bar@baz(quux)
to mean
baz(foo.bar, 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.
Consider:
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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
