Alternative proposal to privateName.public

Erik Corry erik.corry at
Mon Dec 26 08:27:05 PST 2011

2011/12/26 David Bruant <bruant.d at>:
> Le 26/12/2011 16:37, Erik Corry a écrit :
>> 2011/12/26 David Bruant <bruant.d at>:
>>> Le 26/12/2011 15:56, Erik Corry a écrit :
>>>> 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__
> I does not prevent conflicts. Only the likelyhood of conflicts since the
> name can be forged by other means than output of your function. In some
> applications it will be fine enough. In some others it won't.

You stated that the unique names are "fully visible to,
Object.getOwnPropertyNames, and proxies".  At that point there is no
sense in worrying about forged unique names.  Anyone can get hold of
the unique name just by looking at an object that uses it.  Making the
unique names unforgeable doesn't help you if the original is there for
the picking.

>> 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.
> I get your point, but 10 years is still better than never. Hopefully,
> we'll still be alive to see it in browsers ;-)
> Though, since you work on V8 and that node.js updates regularly and
> aligns with new V8 versions, it's likely that people will be able to use
> unique names long before 10 years after you ship the change.

This is true, but it still makes sense to be conservative in what is
added to the language vs. what can be done as an npm module.

> On a side note, I have seen a talk where someone mentionned that the
> "use the same JavaScript in server and client" was partially bullshit,
> because Node has support for some ES5 features that legacy web browsers
> can't even emuate.

It's also partly bullshit because most of the time you want to write
very different code on the server and the client.  For one thing the
trust model is completely different and that has a huge effect on all
the code.  For another the modules infrastructure that you have on
node is (for good reasons, I suspect) completely different to the
infrastructure available on the client, which makes a difference to
the way you structure your program.

Never the less, there is a subset of JS that can be used on both the
server and a given subset of supported clients, which is about the
most you can expect.

Erik Corry

More information about the es-discuss mailing list