Alternative proposal to privateName.public

David Bruant bruant.d at
Mon Dec 26 07:14:43 PST 2011

Le 26/12/2011 15:56, Erik Corry a écrit :
> 2011/12/22 Tom Van Cutsem < at>:
>> At first, I shared Andreas's concern about introducing a flag in feature X
>> that only seems to affect a superficially unrelated feature Y.
>> However, having skimmed the private names page, I stumbled upon a section
>> that seems to want to introduce precisely such a flag for different but
>> related purposes:
>> <>
>> 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
> I don't see how you need anything new in the language to support unique names.
> var newUniqueName = (function() {
>   var counter = 0;
>   return function () {
>     return "__uniquename__" + counter++;
>   };
> })();
I think that in the proposal, the definition of "unique" is "unique
across the program".
And this can't be achieved in JavaScript since no program can know, at a
given time, which names are used and which are not. It also cannot know
which names will be generated (this last part is undecidable anyway).

If it was considered to introduce a module that contained a property
name in order to access ES5.1 [[Class]], this name could not be a string
since it could conflict with other names used on this object. However, a
unique name could be used.
import className from "@class";

var o = {'class': 1, 'className':2, '[[Class]]':3};
var a = o <| [];

o[className]; // "Object"
a[className]; // "Array"

Despite my effort to make a collision in o definition, I can safely
retrieve the internal [[Class]] of an object since the unique name
stored in the className variable is guaranteed to be unique.

This will also allow implementors to experiment whatever they want
without polluting objects, nor doing weird string-based "property-like
non-properties" like '__proto__', '__noSuchMethod__'.

I don't know for [[class]], but iterators [1] already propose such a thing.



More information about the es-discuss mailing list