On 02/11/11 14:05, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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'.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
