On Mon, Jan 28, 2013 at 11:27 PM, Brandon Benvie <[email protected]>wrote:
> I realized the discrepancy between my thinking and what you said. In the > case of a membrane, you are correct. A membrane will always unwrap > everything, so you will only ever end up with dry method/dry this. That > makes all the different forms of private equivalent. > Hi Brandon, just to be clear, so this statement of "equivalence" is not misunderstood later: They are "equivalent" only in the limited scenario you outline, where the private-symbol/weakmap does not cross the membrane boundary. When it does, for all eight cases that arise, the weakmap maintains transparency. The private-symbol does not. > The difference arises when you're not dealing with a membrane, rather just > a one shot proxy. In this case, you often do end up with (to borrow > membrane the membrane terminology) dry method/wet this. this is the > specific circumstance (and I believe the likely most commonly encountered > one) in which auto-unwrapped private symbols do the right thing when the > other private forms fail to work correctly. > > On Monday, January 28, 2013, Mark S. Miller wrote: > >> So the corresponding WeakMap situation would be one where the WeakMap o2 >> is never passed through the membrane, so there is no p2 on the other side >> of the membrane. In that scenario, AFAICT PrivateSymbol proposal #1, #2, >> and WeakMaps are all equivalent. Not so? >> >> >> On Mon, Jan 28, 2013 at 4:19 PM, Brandon Benvie < >> [email protected]> wrote: >> >>> The assumption that my conclusion on auto-unwrapping rests on is that >>> the situation shouldn't arise where a wet value is set as a dry object's >>> private property. The reasoning is that the private key is presumed to be >>> something closely guarded and that won't be shared in such a way that this >>> happens. This assumption is the underpinning of the whole thing, so it's >>> the real point of contention. >>> >> >> >> >> -- >> Cheers, >> --MarkM >> > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
