Are Private name and Weak Map the same feature? and the Assoc API
bruant.d at gmail.com
Wed Dec 21 06:24:21 PST 2011
Le 21/12/2011 13:59, Andreas Rossberg a écrit :
> On 21 December 2011 13:33, David Bruant <bruant.d at gmail.com> wrote:
>> Le 21/12/2011 11:25, Andreas Rossberg a écrit :
>>> In essence, you are introducing two separate types of private names,
>>> but the distinction only is observable in situations that the
>>> implementer should not need to think about in the first place.
>> I don't know to what extent this is a receivable arguments. There are
>> other instances of "the implementer should not need to think about in
>> instance, WeakMaps and Maps.
>> As a programmer, I want an object -> value map. Why am I given 2
>> almost-similar features to do this? Because it's an undecidable problem
>> to know whether or not the program is going to iterate over the keys, so
>> 2 features are created. One without key enumeration and one with
> I don't think these examples are comparable. In any case, every
> programming language, except the bare lambda calculus, has semantic
> arguments? You could as well pass an object. (And in fact, some
> languages work along these lines.)
> There are pragmatic reasons for introducing redundancy.
That's what I was justifying too with the introduction of Maps and
WeakMaps in the language. I think we agree on that, don't we?
> And the
> properties of weak maps vs private names are sufficiently different
> beyond a superficial abstract level to warrant the redundancy.
In the part you're responding to, I was comparing Maps and WeakMaps, not
WeakMaps and private names.
Regarding my initial message, even if the title suggests that 2 features
could be "the same", I did not argue towards removing any of the 2.
It was more of a reflection toward unifying a low-level component that
could be used in both case.
>>> What would be the guideline for picking the right one?
>>> When would I ever want to pick the weaker variant?
>> You would pick the weaker variant whenever you would share a
>> public->private name map under the current proposal (which is when you
>> want a proxy to have access to the private name).
> OK, that's what I'd refer to as the "stronger" variant :) (in the
> sense of being somewhat safer wrt privacy). So when would you pick the
Sorry for the interpretation confusion. To answer more in detail to your
With current proposals, as far as proxies are concerned, the secret is
not that much the private name anymore. It rather is whether or not the
proxy has a way to find the private name based on a public name.
So, sharing or not a private name with a proxy requires an action from
the private name holder, this action being to share a public->private
mapping mechanism with the proxy
Since an action is required from the private name holder to share the
name, my suggestion is to make it more explicit with the boolean which
in essence says "I want this private name to be shared with proxies" or
"I don't want this private name to be shared with proxies".
Current proposals need creating, maintaining and sharing a map to
achieve this. Mine needs to choose the right boolean. In doubt or if you
don't case, don't choose a boolean and "false" (the safer case) is
chosen for you by default.
So, to answer your question, you choose your boolean value based on the
same criteria than previously: based on whether or not you want your
secret to be shared to proxy handlers.
With current proposals, the implementation side of answering this
question is deciding whether or not to create and share a map. And, of
course, if you don't ask the question to yourself, you likely default to
not creating a map and not sharing... like in my proposal.
Specifics are different, but the baseline between my proposal and the
current one is the same: by default, don't share a private name with a
I make the "I want to share with proxies" case a more straightforward.
And the "I want to share with some proxies, but not some others" case
remains complicated, which, I think, is fair.
More information about the es-discuss