Le 11/04/2013 14:23, Tom Van Cutsem a écrit :
2013/4/11 David Bruant <[email protected] <mailto:[email protected]>>
Le 11/04/2013 10:39, Tom Van Cutsem a écrit :
Yes, but this is also the behavior we have today, right? Nothing
new under the sun. I even wonder whether we can change this,
wouldn't it be backwards-incompatible?
I'm only interested in the semantics of the new syntax, so
backward-compat isn't a concern.
o1@o2 coercing o2 to a string when it's an object would be
consistent with what we have today, but I don't believe today's
o1[o2] behavior is desirable. Maybe I'm wrong. Does anyone have
examples of code making good use of the implicit o2.toString() for
o1[o2]?
Ok, you're right. The new syntax does give us some leeway to change
this behavior. The benefit of sticking to current semantics is that
refactoring o[r] to o@r is less prone to unintended changes.
It could be considered by authors to use syntax to differentiate when
they do something public ([] and .) and something private (@). This
visual distinction would only follow the trend of using _properties in
JavaScript to denote something expected to be private; convention also
used in Dart to denote privacy.
I'm doubtful of the use of strings and symbols in the right-hand side.
Are there default @geti/@seti for Object.prototype?
Not sure if this is necessary: what would these default
implementations do?
The same thing that private symbols would do.
Under this proposal, a private field (aka private symbol) is simply a
{Weak}Map. The @geti/@seti of a {Weak}Map will retrieve or store the
binding like its get/set methods would.
Normal Objects cannot store Object->Object bindings, only
String->Object bindings, so I don't see how the default @geti/@seti
implementation on Object.prototype could do the same thing as those on
{Weak}Map.prototype.
By using a WeakMap under the hood. Trying to give a try of what I would
expect; this is a functional definition using code, not a formal
specification (especially when it comes to how storage is performed):
(function(){
// nested weakmaps
var mappings = new WeakMap();
Object.prototype[@geti] = function(o){
var thisMappings = mappings.get(this);
if(!thisMappings)
return undefined;
return thisMappings.get(o);
}
Object.prototype[@seti] = function(o, v){
var thisMappings = mappings.get(this);
if(!thisMappings){
thisMappings = new WeakMap();
mappings.set(this, thisMappings);
}
thisMappings.set(o, v);
}
})();
// following this definition, we have:
var o = {}, r = {}, r2 = {};
o@r = 12;
console.log(o@r); // 12
console.log(o@r2); // undefined
console.log(r@o); // undefined
As I wrote "Object.prototype[] = ", I realized that this is global
authority that opens an undesired communication channels. If that's the
case, another idea would be to be able to generate such @geti/@seti
pairs (so that only parties with access to a given pair have access to
the related storage). Per-class pairs could be generated to have
per-class private properties, etc.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
