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

David Bruant bruant.d at gmail.com
Wed Nov 2 10:53:35 PDT 2011

Le 02/11/2011 17:05, Jeremy Ashkenas a écrit :
> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant <bruant.d at gmail.com
> <mailto: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.
Thanks for your response.

> What draws people to dynamic languages is freedom.
What drew people to JavaScript originally was that it was the only
language of the web on the client-side. No other reason. If the language
used to manipulate the DOM had been strongly typed, that's what we would
be using. If from the start it had non-mutable prototype, we couldn't
have fixed most browser bugs, write things like es5-shim or a bunch of
other polyfills. (by the way, thanks M.Eich for including this brilliant
idea in JS!)

> 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)
Well, let's talk about it. Why on Earth am I forced to open an iframe to
safely discuss with another script? That's such a waste of resources.
And how can mutually suspicious scripts can communicate safely in JS
environment where there are no iframes? Well... they can't... (with SES,
now they can, but it took some time)
We have accepted that people can't use scripts from different origins
for the only reason that JS had no way to write programs defensively and
because there is no way to take a script from somewhere else and prevent
it from breaking everything.

> 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.
Following this logic, "var" does not add anything to a variable. If you
don't want the variable to be used outside a function... don't use it
outside the function.
Are you also against "let"? it reduces even more where a variable can be

More seriously, if you're the only programmer, yes, I agree with what
you said. If I give you a library, without telling you what is private
and what isn't, you are likely to break the library. If I keep private
what should be, you won't mess with my code. Using private
variables/properties is a way for me to make sure you do not use what
you shouldn't. It protects you from changes if I do internal changes to
my library.
The less I allow you to do, the stricter is your use of my library and
the less work you need to do.

> 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.
If a private method can be accessed externally, well, it's not private.
If you can change a constant, it is not a constant, regardless of what
keyword can say.

> 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.
I cannot agree more. In no way I am advocating for "locked-down by default".
What I'm advocating for is "i can lock things down if I want to in my
application". This is what "const", "private" and the like offer. The
option for me to make my choice.
I don't want locking things down. I just want the choice to do it myself
in my application if I want to.

> 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.
And duck-typing also allows to work around browser bugs. I would not
sacrifice that either.
But in the large majority of code I have come across, the freedom is
used as follow:
1) arrange environment (duck-type to fix bugs, add things, wrap
functions for logging, etc.)
2) run your application.

If you disagree with this pattern, please provide examples.
The first step uses the freedom. The second step just use the
environment and created objects and doesn't mess around with existing
things anymore.
In this case, the benefit of locking down everything after step 1 is
that it protects from mistakes or malicious code and looses no potential.
Above, you mention that large-scale Ruby projects change some things
during "configuration". I think it's what i describe as step 1.

In another mailing-list Mark Miller mentioned the existence of a paper
that showed that 2 step pattern for Python. Is anyone aware of what
paper that is?

> 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.
This is pure speculation. I could say the opposite and be as much right.
In the real world, thousands of people use Java interfaces to understand
what classes do and especially what they don't do. You write an
interface with in mind the idea of providing a service and hiding
implementation details. If an interface doesn't do what you want,
inherit from it, create another interface, but there is no reason to
change the interface, because the some people want the exact service it

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

More information about the es-discuss mailing list