Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Mikeal Rogers mikeal.rogers at gmail.com
Wed Nov 2 14:40:38 PDT 2011


>>> This is a contrived case, but in general, because JS objects are mutable, and when they're used as prototypes they stand in for class vtables, something has to pay a price. Either you worry about checking on every d.m(i) call that the cached target method in b is still the one to call, or you emit code that doesn't check but tear it up and throw it away when c.m is injected and shadows b.m.
>>> 
>>> This is fine with me and worth the price, but it clearly is not for everyone.
>> 
>> I don't think I've ever heard an active JavaScript developer, who has been programming in JavaScript longer than 6 months, ask for private class or instance variables. Maybe you have, you talk to more people than I do. I do hear this a lot from people who don't use JavaScript and likely won't even if we add it.
>> 
> 
> The module pattern, arguably one of the most common JS patterns out there is predicated on making internal variables 'private' via a closure, and only returning a 'public' API. For any class/type defined, there are vars that are likely to be only used within the implementation or they are vital to the class/type contract. Both are compelling reasons to have private. 

For some background, I wrote one of the revisions of the commonjs modules specification and I wrote the CouchDB implementation of that spec and I work, infrequently, on node.js' implementation.

I don't think your comparison is accurate. 

You *must* be allowed to customize the return value of require("mymodule"), just like you can customize the return value of a function call, and require() is a function call. 

While it may not be obvious to the user, the reason the scope is private by default is because you have to do a function wrapped eval in order to allow customization of the return value from require(), not the other way around as your comment would suggest.

The fact that module variables and methods default to private is actually a source of pain. For example, we have exposed previously internal objects and methods to the exports object in bugfix releases of node.js because there was no other way to work around a bug or customize important or broken behavior. The fact that they weren't public by default means that we now have forward incompatibility problems in point releases of node.js. 

If every js implementation had an eval sandbox where we could pass in and return a new scope commonjs modules may have done that by default and only made that scope private when the user intended to customize the return value. I would have advocated it, but commonjs modules had to be written for the lowest common denominator so that was never an option. In fact, the commonjs spec can't even support node.js' `module.exports = function () {}` because it can't work in some environments.

-Mikeal


More information about the es-discuss mailing list