Re: Questioning WeakMap.prototype.clear

I would like to humbly say that if this `WeakMap#clear()` method is anyhow slowing down or reminding the adoption of the WeakMap concept itself for all browsers, just mark it TBD and go on with the rest: WeakMap is needed and wanted since ever, `clear()` gotchas can be discussed for all the time we

Re: Questioning WeakMap.prototype.clear

I've been following the threads on WeakMap.prototype.clear with interest, and I think I may have an argument that should make the existence of WeakMap.prototype.clear irrelevant from an ocap security perspective. It was already previously suggested in this thread that the ocap thing to do would be

Re: Ducks, Rabbits, and Privacy

My initial reaction: - Hosting getPrivate/setPrivate on Object seems quite strange to me. - it seems unrealistic to me to ask developers to write so much code every time they want to use their own private instance variable. The notion of Private should be specified once for an instance variable,

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Brandon Benvie wrote: It is my opinion that the primary use case for private symbols is for properties that proxies expressly shouldn't be given a chance, in any manner, to corrupt or modify. They are likely used for sensitive internal state that will only be accessed by methods or friend class

Re: Ducks, Rabbits, and Privacy

A Duck/Rabbit Proposal: 1) There is only one kind of Symbol 2) Private data can be accessed via Object.getPrivate and Object.setPrivate The goal is to provide a base-level API from which higher-level abstractions can be built. // === Basic example === var symbol = new Symbol(), obj = {};

Re: WeakMap.prototype.clear performance

On Jan 22, 2013, at 4:00 PM, Mark S. Miller wrote: > Should Symbols (whether unique or private) also have a .clear method, > in order to delete all properties named by that symbol? Of course not. A Symbol is basically a simple immutable value disguised as an object. The is no interesting abstr

Re: WeakMap.prototype.clear performance

Should Symbols (whether unique or private) also have a .clear method, in order to delete all properties named by that symbol? On Tue, Jan 22, 2013 at 3:36 PM, Allen Wirfs-Brock wrote: > > On Jan 22, 2013, at 2:35 PM, David Bruant wrote: > >> >> So, to find out if a weakmap is dead, it has to come

Re: WeakMap.prototype.clear performance

On Jan 22, 2013, at 2:35 PM, David Bruant wrote: > > So, to find out if a weakmap is dead, it has to come from another source than > the mark-and-sweep algorithm (since it losts its precision)... > Given the additional prohibitive cost weakmaps seem to have on the GC, maybe > things that would

Re: WeakMap.prototype.clear performance

Thanks a lot for these explanations! (Answer below) Le 22/01/2013 22:46, Jason Orendorff a écrit : Having said all that, I bet we could hack around the worst-case GC performance. It'll be a pain, but GC is like that sometimes. What you said above about the current GC setup that yi

Re: WeakMap.prototype.clear performance (was: Questioning WeakMap.prototype.clear)

On Tue, Jan 22, 2013 at 1:46 PM, Jason Orendorff wrote: > On Tue, Jan 22, 2013 at 1:55 PM, David Bruant wrote: >> >> For reference, quote from Allen: >> >> generational collectors can have large latencies between the time the last >> reference to an object is destroyed and the when the GC actuall

Re: Ducks, Rabbits, and Privacy

On Tue, Jan 22, 2013 at 4:03 PM, Kevin Smith wrote: > > >> +1 to this and everything else Nathan has said. Watching all this intense >> back and forth, there are a lot of good points, some of which almost >> convince me that weak maps are sufficient and private symbols are >> unnecessary. But whe

Re: WeakMap.prototype.clear performance (was: Questioning WeakMap.prototype.clear)

On Tue, Jan 22, 2013 at 1:55 PM, David Bruant wrote: > For reference, quote from Allen: > > generational collectors can have large latencies between the time the last > reference to an object is destroyed and the when the GC actually notices. > Many GC cycles may occur during that period and if a

Re: Questioning WeakMap.prototype.clear

Le 22/01/2013 15:59, Jason Orendorff a écrit : A) Are there more WeakMap applications that will want .clear() or applications that will want .clear() not to exist? Offhand I would bet on the former, by a landslide, but if you think otherwise, or if there's some other reason to privilege .clear(

Re: Ducks, Rabbits, and Privacy

> > +1 to this and everything else Nathan has said. Watching all this intense > back and forth, there are a lot of good points, some of which almost > convince me that weak maps are sufficient and private symbols are > unnecessary. But when I step back for even a minute, as a developer private > sy

Re: Ducks, Rabbits, and Privacy

This is very well said. But your assertion that the external model is "unnatural" does not necessarily hold. Again, let's look at this private syntax and expansion using WeakMaps: https://gist.github.com/4561871 This syntax presents an "external" model of private data (and methods!). Do you th

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Le 22/01/2013 20:05, Tom Van Cutsem a écrit : 2013/1/22 David Bruant mailto:bruan...@gmail.com>> Just realizing now, but how does the membrane do the symbol unwrapping if private symbols pierces it? 2 contexts A and B share a symbol, the symbol initially has to go through a publi

WeakMap.prototype.clear performance (was: Questioning WeakMap.prototype.clear)

[Merging a couple of relevant posts] Le 22/01/2013 15:59, Jason Orendorff a écrit : Now, the only thing that can differentiate both the native against this version is performance I think. Allen seems to argue that a native .clear would have better perf characteristics (related to

Re: Ducks, Rabbits, and Privacy

It's my opinion that saying that closures should be used for an object to hold onto private data, as you are advocating, is in conflict with ES's prototypal model of inheritance. Methods cannot both (A) be on a constructor's prototype and (B) live inside the scope used to house private data. The

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

2013/1/22 David Bruant > Just realizing now, but how does the membrane do the symbol unwrapping > if private symbols pierces it? > 2 contexts A and B share a symbol, the symbol initially has to go through > a public channel (get trap with a string name for instance) and if A > created a symbol a

Re: Questioning WeakMap.prototype.clear

Le 21/01/2013 22:42, Allen Wirfs-Brock a écrit : On Jan 21, 2013, at 12:25 PM, David Bruant wrote: Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit : On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote: This is the reality check I can get behind—I'm hard pressed to come up with a use case that i

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Le 22/01/2013 16:13, Tom Van Cutsem a écrit : 2013/1/22 Allen Wirfs-Brock > We can probably fix the built-ins with some ad hoc language about them automatically resolving proxies to the target as the this value. Or perhaps we could expand the internal MO

Re: Ducks, Rabbits, and Privacy

On Tue, Jan 22, 2013 at 11:13 AM, Brandon Benvie wrote: > I also agree with everything that Nathan said. > > To clarify, there's Symbols and then there's private Symbols. I don't > think anyone in TC39 is suggesting the removal of Symbols in general. > Private Symbols have a much more specific set

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

On Jan 22, 2013, at 9:06 AM, Brandon Benvie wrote: > Kevin Smith pointed out something I hadn't though about before but is obvious > in retrospect. The hazard that proxies bring to the language in general: > proxies make it possible to break the target object by inconsistently > handling forwa

Re: Ducks, Rabbits, and Privacy

On Tue, Jan 22, 2013 at 8:13 AM, Brandon Benvie wrote: > I also agree with everything that Nathan said. > > To clarify, there's Symbols and then there's private Symbols. I don't think > anyone in TC39 is suggesting the removal of Symbols in general. Private > Symbols have a much more specific set

Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Kevin Smith pointed out something I hadn't though about before but is obvious in retrospect. The hazard that proxies bring to the language in general: proxies make it possible to break the target object by inconsistently handling forwarding during the operation of methods. class Counter {

Re: Questioning WeakMap.prototype.clear

On Jan 22, 2013, at 7:18 AM, Mark S. Miller wrote: > > But WeakMaps were introduced specifically to support rights > amplification[1]. Perhaps, from your perspective, but not from mine. The above is certainly not a phrase I would ever say, I'm not even sure of your exact technical definition

Re: Questioning WeakMap.prototype.clear

On Tue, Jan 22, 2013 at 9:01 AM, David Bruant wrote: > class WeakMapWithoutClear { > Yep. Glad to see we are thinking along the same lines. > What this and my previous show is an semantics equivalence between > clearable and clear-less weakmaps. Which should be chosen as default? > * clear

Re: Ducks, Rabbits, and Privacy

I also agree with everything that Nathan said. To clarify, there's Symbols and then there's private Symbols. I don't think anyone in TC39 is suggesting the removal of Symbols in general. Private Symbols have a much more specific set of uses cases than do just Symbols in general, and regular Symbol

RE: Ducks, Rabbits, and Privacy

> The fact that ES built-ins' methods are defined on the prototype **and** have > access to private data seems to indicate that the ideal model would allow > both. WeakMaps do, to a degree, permit both, but it's just a hack. If it > wasn't, the ES spec itself would describe built-ins' private da

Re: Questioning WeakMap.prototype.clear

On Tue, Jan 22, 2013 at 2:47 AM, Jason Orendorff wrote: > On Mon, Jan 21, 2013 at 6:04 AM, David Bruant wrote: >> >> [...] WeakMap.prototype.clear questions the property that was true before >> its adoption ("you can only modify a weakmap entry if you have the key") > > > David, would you please

RE: Ducks, Rabbits, and Privacy

Kevin Smith wrote: > In ES5, there is no distinction between "public" and "private" data within > an object.  If you want to create private data, you must do so using a > closure.  All private data is therefore "external" to the object in > question.  The data does not "follow" the object around. 

Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

2013/1/22 Allen Wirfs-Brock > We can probably fix the built-ins with some ad hoc language about them > automatically resolving proxies to the target as the this value. Or perhaps > we could expand the internal MOP api to include a resolve proxy to target > operation. > > Using private symbols fo

Re: Security Demands Simplicity (was: Private Slots)

Le 22/01/2013 16:02, Tom Van Cutsem a écrit : 2013/1/22 David Bruant mailto:bruan...@gmail.com>> Le 21/01/2013 22:31, Tom Van Cutsem a écrit : Let's talk through Allen and Brandon's suggestion of auto-unwrapping private symbol access on proxies. If a membrane can int

Re: Security Demands Simplicity (was: Private Slots)

2013/1/22 David Bruant > Le 21/01/2013 22:31, Tom Van Cutsem a écrit : > > Let's talk through Allen and Brandon's suggestion of auto-unwrapping >> private symbol access on proxies. >> If a membrane can intercept all exchanged private symbols I think this >> could be made to work. >> > Agreed. Un

Re: Questioning WeakMap.prototype.clear

Le 22/01/2013 15:19, Jason Orendorff a écrit : On Tue, Jan 22, 2013 at 5:56 AM, David Bruant > wrote: Le 22/01/2013 11:47, Jason Orendorff a écrit : On Mon, Jan 21, 2013 at 6:04 AM, David Bruant mailto:bruan...@gmail.com>> wrote: [...] WeakMap.prototy

Re: Questioning WeakMap.prototype.clear

On Tue, Jan 22, 2013 at 5:56 AM, David Bruant wrote: > However, Mark showed an elegant way to implement .clear on top of > clear-less weakmaps and the class syntax [4][5] (reproducing here the final > version for clarity) > Sure—and roughly the same code can be used to *remove* an unwanted .clea

Re: Questioning WeakMap.prototype.clear

On Tue, Jan 22, 2013 at 5:56 AM, David Bruant wrote: > Le 22/01/2013 11:47, Jason Orendorff a écrit : > > On Mon, Jan 21, 2013 at 6:04 AM, David Bruant wrote: > >> [...] WeakMap.prototype.clear questions the property that was true before >> its adoption ("you can only modify a weakmap entry if

Re: Security Demands Simplicity (was: Private Slots)

Le 21/01/2013 22:31, Tom Van Cutsem a écrit : Let's talk through Allen and Brandon's suggestion of auto-unwrapping private symbol access on proxies. If a membrane can intercept all exchanged private symbols I think this could be made to work. Agreed. Unfortunately, I think the condition ("If a m

Re: Questioning WeakMap.prototype.clear

Le 22/01/2013 11:47, Jason Orendorff a écrit : On Mon, Jan 21, 2013 at 6:04 AM, David Bruant > wrote: [...] WeakMap.prototype.clear questions the property that was true before its adoption ("you can only modify a weakmap entry if you have the key") David,

Re: Questioning WeakMap.prototype.clear

On Mon, Jan 21, 2013 at 6:04 AM, David Bruant wrote: > [...] WeakMap.prototype.clear questions the property that was true before > its adoption ("you can only modify a weakmap entry if you have the key") > David, would you please elaborate your argument for this invariant? This the first I've se

Re: Ducks, Rabbits, and Privacy

Le 22/01/2013 07:31, Benoit Marchant a écrit : Why can we express in a property descriptor the notion of writable, configurable or enumerable but not private? Because strings are forgeable, meaning that someone you may not trust can read in your code or guess (maybe with low probability) the nam