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

[Quildreen Motta]

On 02/11/11 14:05, Jeremy Ashkenas wrote:
> 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.
>
> What draws people to dynamic languages is freedom.
I'd put `extensibility' and `expressivity' here instead, but sure. And 
JavaScript does pretty good at that --- not as much as Lisp, but oh 
well, it's not like I expected a C-family language to be that extensible :3

> 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".
Agreed. But there are other things here other than "security constraints".

> "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.
I still haven't found an use to private either, to be honest. Granted I 
often declare "private" functions and variables inside a closure, I 
always export them in an `internal' object, so it doesn't clutter the 
core API.

> "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.
I'm not sure I agree here. Constants are not about security they're 
about abstractions. You name something that you'd otherwise have to 
write as a regular expression. In this case, they'd be like a really 
simple inline function, except they do no transformations.

> "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.
Again, immutability isn't just about security, but optimisation as well. 
You could also look at shared-memory threads, because I think they make 
a hell of an argument for "frozen" objects or immutability.

> 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.
Agreed, but note that none of the features above preclude JavaScript 
from being a free language that makes it easier to write the right 
thing. It'll be just as expressive as before. Also note that you can 
already achieve all of those functionality in current JavaScript, so 
having class-literals, as a declarative syntax, support them in a nice 
way is okay.

It's not like any feature can't be abused as you say. But the fact that 
a feature can be abused doesn't mean it should be never considered. 
JavaScript's `with' is a good example of that. You could create the most 
awesome and expressive module library using that, but no vendors have 
optimized it (as far as I know) because people considered it could only 
ever be abused and haven't used it.

Also, note that `with' makes a whole awesome use-case for `Object.freeze':

---
with (require({'library1': 'lib1'}, {'library2': 'lib2'})) {
   lib1.foo(lib2.something)
}
// Would be equivalent to Python's
// import library1 as lib1
// import library2 as lib2
//
// But restricted to a block.
---

You could also use it as a dynamic let, and just as long as you freeze 
the object passed to `with', there's no reason one shouldn't optimize it 
as just a regular EnvironmentRecord lookup. Using `let' instead of `var' 
removes the thing about variable hoisting declaring the variable outside 
of the `with' scope, etc.

tl;dr; While `private', `const' and `freeze' could certainly be abused, 
that doesn't mean they don't have value... well, perhaps except for 
`private'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/c7224bd6/attachment.html>