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

David Bruant bruant.d at gmail.com
Wed Nov 2 14:26:45 PDT 2011


Le 02/11/2011 21:27, Mikeal Rogers a écrit :
>
> On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
>
>> 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.
Your own code:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
Line 35, you define the function stopBuffering (keeping only relevant
parts):
----
function File (options) {

  var stopBuffering = function () {
    // ...
  }

}
----
Why didn't you do this.stopBuffering = function(){}?

Maybe you used the keyword "var", but you effectively created a private
method of your "File" class. With a class syntax, you would have used
the "private" keyword to achieve the same thing.
Maybe you don't call it this way, but you use (and de facto ask for)
privacy.

> 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.
Who are these people? You are saying that there exists people who don't
use JavaScript but want to change the language? This sounds like a crazy
idea. Regardless, why should we be listening to them?


>> I'm not just talking about implementors, either. Some users will want
>> to know d.m isn't going to change. They may not want to know that
>> it's b.m, mind you -- they simply won't want that c.m assignment to
>> be legal, or else if they do support such a thing, they don't want it
>> to affect d's "vtable".
>>
>> Ok, so such people should use another language than JS. Or, perhaps,
>> they could freeze c and b.
>
> I would argue that developers who rely on these kinds of assurances
> are actually slowing down their own, and others, productivity.
This is maybe true.
For some people, productivity is not a priority. Some people want to be
able to prove their program is correct, some people want security, some
people want reliability and they prioritize these things higher than
productivity. Should we close them the door to JavaScript?

> Assuming they wrote the perfect method and it should never be changed
> is a grand claim for anyone who isn't Donald Knuth. Assuming that the
> consumer of their code is responsible for their own bugs if they
> introduce them with monkey patching class methods seems fair.
>
> I think this is what Jeremy is getting at, not having these features
> (or at least obscuring their use to be a different, more explicit
> pattern, using closures) actually leads to longer term productivity
> and sustainability in the community and I tend to agree
This is pure speculation. I think these features won't change anything.
There is a strong culture of monkey-patching and using the dynamicity in
JavaScript. I think that if a library is too strongly locked-down it
will be unpopular, so either people will not use it, rewrite another one
with the same features or fork (if open source) and unlock. Because of
the cultural aspect, people will keep things unlocked, not changing
anything to long-term productivity and sustainability.

David

Ps:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R64
You could do "process.nextTick( stopBuffering )" instead of creating an
anonymous function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/81a6fc4c/attachment.html>


More information about the es-discuss mailing list