Alternative proposal to privateName.public

David Bruant bruant.d at
Mon Dec 26 10:34:36 PST 2011

Le 26/12/2011 14:40, David Bruant a écrit :
> (...)
> 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
Regarding unforgeable names as part of standard libraries (like for
[[class]] or 'iterator'), it seems that for these two examples, these
are things that all objects already "have", so it would make sense that
all objects have a value for it (at least for [[Class]]).

However, if these unique property names were visible, it could break
backward compatibility:
var o  = {a:1};
If property names for iterator or [[Class]] were visible, then the above
snippets would have a different behavior in ES5 and ES6.
So, standard unforgeable names, if they refer to something objects all
have should be invisible.

Moreover, these standard names have no reason to be hidden from proxies
(one more argument against having a systematic private -> public
translation when trapping). So it seems they should be trapped.

So it seems to me that these standard private names should be invisible
and trapped (case 2 from above).


More information about the es-discuss mailing list