2011/12/22 Tom Van Cutsem <tomvc...@gmail.com>:
> At first, I shared Andreas's concern about introducing a flag in feature X
> that only seems to affect a superficially unrelated feature Y.
>
> However, having skimmed the private names page, I stumbled upon a section
> that seems to want to introduce precisely such a flag for different but
> related purposes:
> <http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#possible_visibility_flag>
>
> Having also just read about the different use cases of "private" names
> versus just "unique" names, it would make a lot of sense to me if we would
> separate these two (either via a flag or via different constructors):
>
> - private names: invisible to for..in, Object.getOwnPropertyNames, and even
> proxies
> - unique names: fully visible to for..in, Object.getOwnPropertyNames, and
> proxies


I don't see how you need anything new in the language to support unique names.


var newUniqueName = (function() {
  var counter = 0;
  return function () {
    return "__uniquename__" + counter++;
  };
})();


var MyClass = (function() {
  var private1 = newUniqueName();
  var private2 = newUniqueName();
  return function() {
    this.my_public_variable = 0;
    this[private1] = 1;
    this[private2] = 2;
  }
})();

var my_instance = new MyClass();

I'm a big fan of building what we need out of what we have rather than
adding more and more to the language.  Benefits include:

* Keeps VM complexity down
* Available now on all browsers
* If it turns out to be dumb we are not stuck with it for all eternity


> By tying the flag to use cases of private names (are you interested in the
> name's privacy or its uniqueness?), it makes more sense to include it in the
> API.
>
> Cheers,
> Tom
>
> 2011/12/20 David Bruant <bruan...@gmail.com>
>>
>> Le 17/12/2011 14:24, David Bruant a écrit :
>> > (...)
>> >
>> > # Proposal
>> >
>> > What about a 'trapped' boolean in the private name constructor?
>> >
>> > It would work this way:
>> >
>> > `````JavaScript
>> > var n = new Name(false); // don't trap when used is a proxy
>> > var p = new Proxy({}, maliciousHandler);
>> >
>> > p[n] = 21; // the set trap is NOT called!
>> > var v = p[n]; // the get trap is NOT called and v === 21
>> > `````
>> >
>> > Basically, when the private name is created with the 'trapped' boolean
>> > to false, the proxy becomes oblivious to being called with these private
>> > names.
>> There has been some other proposals suggesting ways to bypass the proxy
>> to work directly on the target. Since I have been brief, my proposal
>> could be interepreted as such and it was not my intention. So here are
>> additional code snippets to further explain my proposal.
>> -----
>> var n = new Name(false); // untrapped name
>> var t = {};
>>
>> var p = new Proxy(t, maliciousHandler);
>>
>> p[n] = 21; // the malicious set trap is NOT called!
>> var v = p[n]; // the malicious get trap is NOT called and v === 21
>>
>> Object.getOwnPropertyDescriptor(t, n); // undefined
>> -----
>>
>> In this proposal, in the case of untrapped names, only the proxy
>> identity is used internally. No trap is called and the target remains
>> untouched.
>> There is neither implicit nor explicit forwarding to the target. If the
>> code in possession of both a reference to the private name and a
>> suspicious object does not want the suspicious object to have to do
>> anything with the name, it can define the private name as untrapped and
>> the proxy will be oblivious to the private name.
>>
>> This choice is made in order to make the private name owners responsible
>> for what they do with the private name, choose who they want the name to
>> be shared with.
>>
>> David
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to