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

On Wed, Nov 2, 2011 at 11:01 AM, David Bruant <bruant.d at gmail.com> wrote: > Could you elaborate on this point? > All object-lockdown I can think (non-configurability, non-writability, > non-enumerability, private names, const variables, const classes) of is > optional. Why are you against them? > > I was about to say "if you're unsatisfied, create a language which doesn't > provide features you don't like, like Coffeescript", but... humm... > So, why being against the introduction of features in the language? > I'd be glad to elaborate -- but since it's off topic for minimal classes, changing the Subject here. What draws people to dynamic languages is freedom. And JavaScript is one of the *most* dynamic of the mainstream programming languages. Not only can you can pass any object to any function, but you can call a method with any number of arguments, easily modify the prototypes of other objects, introspect on any object's properties with a simple loop, replace any member function with a wrapped version, attach new properties to any object ... the list goes on. If I had my druthers, JS.next would generally embrace the spirit of JavaScript's dynamism (and freedom), and try to push those aspects further -- with better introspection and more flexibility -- instead of compromising with more restrictive static languages and adding lock-down keywords so that some programmers might "feel safer". Let's set arguments about security and constraint guarantees aside for a moment (although I'd be glad to have those as well), and talk about these keywords as pure features: "private" does not add anything new to a property. If you don't want the property to be used outside of the class ... don't use the property outside of the class. "const" does not add anything new to a variable. If you don't want to change the value of a variable ... don't change the value of the variable. "freeze" does not add anything new to an object. If you don't want to change the shape of an object ... don't change the shape of the object. Note that Ruby, another very dynamic language, has "private" and constants. And yet private methods can be called from the outside, with "send", and contants can be explicitly overwritten with new values. They are simply red tape, not concrete walls. For better or for worse, I have very rarely seen a large-scale Ruby project that does *not* call a private method externally, or overwrite a constant during configuration. The recent JavaScript renaissance that we're all enjoying owes debts to JavaScript's foresight as a "free", dynamic language. If all of the JavaScript core object had been frozen, locked down with private methods, and set as const properties on the global object, libraries like Prototype.js never would have happened. Libraries like jQuery would have been much more difficult to imagine. We might not have the new Array#map, #reduce, #every, or #filter methods at all. Can a free, dynamic language be abused? Certainly. Is Prototype.js dangerous? For some websites, it can be (including NYTimes.com, where I work). The freedom of having every object and every property be configurable, settable, introspectable, readable and writable, at least at the language level, is worth the trade off. If we add const, private, and other lock-down syntax, or make class properties private by default (shudder), I guarantee you that many potential innovative libraries that otherwise might spring up will never even be conceived, and frustrating situations that could have otherwise been solved by a quick patch will instead require convoluted work-arounds. JavaScript should be about making it easier to write the right thing, and not so much about making it harder to do the wrong thing. After all, the former is purely positive, and the latter assumes that you know better than the engineer who comes after you. In the real world, you often don't. Cheers, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/26b698cf/attachment-0001.html>