Feedback on the Relationship strawman

David Bruant bruant.d at gmail.com
Thu Apr 11 05:47:37 PDT 2013


Le 11/04/2013 14:23, Tom Van Cutsem a écrit :
> 2013/4/11 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     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 at 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 at 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 at r = 12;
     console.log(o at r); // 12
     console.log(o at r2); // undefined
     console.log(r at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130411/c79f60b6/attachment.html>


More information about the es-discuss mailing list