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