Private name objects and monkey patching

David Bruant bruant.d at
Sun Mar 4 13:48:37 PST 2012

Le 03/03/2012 12:26, Axel Rauschmayer a écrit :
> Quote: “We could extend this to allow the passing of an optional visibility flag (defaults to false) to create(). [...] This would be useful for e.g. modular monkey-patching.”
> Really true? Would the ability to see a uniquely named property help with monkey-patching? If there are several of them, it would be impossible to guess which is which.
To take the recent example of Array.prototype.contains for which there
has been some debate, the 2 different visions could be implemented and
used as module. Each module would create a private name, use it to
create its own version of Array.prototype.contains and export it as a
module export:
// In the 2 different libraries:
var contains = Name(true);
Array.prototype[contains] = function(e){/*different code according to
export contains;

In client code, you can import both modules. The 2 definitions coexist
on Array.prototype without colliding. In your own code, you can rename
the imported private names in a way that makes sense to you.

In this case, encapsulation is not necessary, so there is no need for
the name to be private. Unique is the property that is being looked for.

That's my understanding of the proposal.
For regular code, I have no opinion yet over whether it's a good idea or

However, interestingly, it is a good occasion for library authors to
start creating built-in extensions AND spreading them without the risk
of step on other's toes. It is also an occasion for web browser to
innovate as well without forcing a string-named property which would
risk to become de facto standard.
For instance, in a world with private names,the good choice for
__proto__ or __noSuchMethods__ would be to use a private name :-)


More information about the es-discuss mailing list