>>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
