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

Jeremy Ashkenas jashkenas at gmail.com
Wed Nov 2 09:05:39 PDT 2011

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/26b698cf/attachment-0001.html>

More information about the es-discuss mailing list