Le 17/12/2011 22:37, David Herman a écrit : > On Dec 17, 2011, at 4:04 AM, David Bruant wrote: >> I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy. > This is just a non-starter. Then you can't use private names as private names. I have read a lot of code that I have written myself and I admit that if I wanted to switch to private names, I would make myself vulnerable to the attacks mentionned and would be required to use closures anyway, so as you say, I wouldn't be able to use private names as private names.
>> (One good news is that mostly static analysis >> can assist us in finding where we may disclose 'n' in this scenario). > When you say "static analysis can solve this" you're saying "some > hypothetical approximation to an undecidable problem will find out all the > places where the unstated and unwritten intentions of the programmer were > violated. Also, despite the fact that it's mathematically impossible for such > a tool to have both no false positives and no false negatives, it will still > be both safe and useful." I'll believe it when I see it? I was careful to say "assist" and not "solve". > Besides, we shouldn't knowingly add features that will invite bugs that can > only be found with (as yet unspecified and non-existent) additional > development tools. I agree. >>> And there's no way you can fix >>> this, without resorting to some other method of hiding things like >>> closures. >> I disagree, there is. >> In the case where you want the proxy ("worst case", here "proxy" means >> "untrusted third party") to have access to the private name, you need >> the proxy to have access to a public->private map. > You seem to be treating ES6 as being The Ultimate Proxy Language (with some > additional side features). I do not. I'm aware that proxies have benefits and positive things can get out of them. As it turns out, they are heavily used in Firefox as well from what I heard. It would be interesting to hear from the people who have experience with them to know how they feel about private names and the ".public" > Proxies are not the common use case we are optimizing for, nor should they be. > > The common case we are optimizing for has nothing to do with proxies. It's > simple stuff like: > > let n = Name(); > function Stuff() { > this[n] = /* some internal stuff */; > } > Stuff.prototype = { > doStuff: function() { > ... this[n] ... > } > }; > >> If each time I create an abstraction using proxies, I need a >> public->private map, it is likely that I (and it's obviously not about >> "me", but anyone writing proxies) won't use private names with proxies. >> I may just use WeakMaps. > Great -- do that! If proxy writers have to work harder to deal with the > public/private map, so be it! I would much rather tax proxy writers than tax > everyone else. As cool as proxies are, they are not intended to be nearly as > common as the usual simple functions + prototypes abstractions of JS. Have you had a look at my alternative proposal [1]? It seems to solve all concerns raised by anyone (including me) in this thread. David [1] https://mail.mozilla.org/pipermail/es-discuss/2011-December/018908.html _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss