On Nov 2, 2011, at 9:05 AM, Jeremy Ashkenas wrote: > I'd be glad to elaborate -- but since it's off topic for minimal classes, > changing the Subject here.
Thanks for that. > 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. This was a calculated move on my part. I didn't have time to get everything hooked up (or upholstered ;-), so I made almost everything mutable (note how Date.prototype, the property not the object value it references, is non-configurable and non-writable; same for other built-ins). This let JS library and app authors monkeypatch and finish things. Now, 16 years later, JS is in a bigger world, it has grown, and three things have happened: 1. Library authors learned the hard way not to patch built-ins, unless the library is Prototype or you take Andrew's "everything is permitted" seriously (many do not). 2. Web developers both depend on and wish to minimize the size (to zero bytes) of libraries. 3. Programming in the large, even ignoring security, means many of us want to save ourselves from assigning to something we want non-writable and initialize-only. That's const. Or we want to avoid name collision worries, never mind hostile attacks, on private data. That's private, or else you use closures and pay some non-trivial price (verbosity and object allocation). (3) implies adding encapsulation and integrity features, on an opt-in basis. (2) means we keep working on the language, until it reaches some macro-apotheosis. (1) does not imply the standard built-in constructors and their prototypes could be frozen -- don't worry about that. We won't break the web. But it suggests that users do not always need all dynamic degrees of freedom, all the time. Some, say SES users, will need to freeze their built-ins in order to build secure mash-ups. ES5 allows this. Why not? My freedom to build a fence doesn't mean I lock the gate. But if I'm dealing with miscreants in the neighborhood, maybe I do put in a lock. Maybe I put in ice-guns and snowball launchers. My choice to do so is part of this "freedom" you advocate. Right? /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
