On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote: > I agree with every sentence in this post. > > +1K :)
Switching to CoffeeScript? :-P /be > > -Mikeal > > On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote: > >> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant <[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. >> >> 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 >> 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. >> >> 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. >> >> Cheers, >> Jeremy >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
