Alternative proposal to privateName.public

David Bruant bruant.d at
Mon Dec 26 05:40:12 PST 2011

Le 22/12/2011 13:20, Tom Van Cutsem a écrit :
> (...)
> 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, Object.getOwnPropertyNames, and
> even proxies
> - unique names: fully visible to, Object.getOwnPropertyNames,
> and proxies
> 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.
I've given more thought to this idea.
For a second, let's imagine we have 2 independent flags: "visible" (or
"reflectable") and "trapped". It would make 4 cases:
1) visible & trapped
2) invisible & trapped
3) visible & untrapped
4) invisible & untrapped

Case 3 would be a bit of a weird beast: the property should in theory be
visible/reflectable, but cannot be trapped in the proxy. This is a
rather inconsistent case.

My original proposal, was to choose between 2 or 4. Tom's proposal is to
choose between 1 and 4. Another alternative would be to have the choice
between 1, 2 and 4 (which would require something else than one or two

I have a slight preference for Tom's proposal as it makes even clearer
that the trapped name can also be found through reflection (with
Object.getOwnPropertyName) and should be handled with care.


More information about the es-discuss mailing list