Alternative proposal to privateName.public

Erik Corry erik.corry at gmail.com
Mon Dec 26 07:37:03 PST 2011


2011/12/26 David Bruant <bruant.d at gmail.com>:
> Le 26/12/2011 15:56, Erik Corry a écrit :
>> 2011/12/22 Tom Van Cutsem <tomvc.be at gmail.com>:
>>> 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:
>>> <http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#possible_visibility_flag>
>>>
>>> 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 for..in, Object.getOwnPropertyNames, and even
>>> proxies
>>> - unique names: fully visible to for..in, 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).

This can be fixed by convention.  As long as there is only one
uniqueName function then the names it makes will be unique.  To ensure
there is only one it can be installed like so:

if (!Object.newUniqueName) Object.newUniqueName = (...  // See above.

The __uniqueName__ string above can be replaced with something like
__i_have_read_and_abide_by_the_unique_name_convention__

If that seems onerous to you consider whether it is really harder than
modifying the VM and then waiting 10 years for your change to be
universally available.

> 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.
>
> David
>
> [1] http://wiki.ecmascript.org/doku.php?id=harmony:iterators


More information about the es-discuss mailing list