Le 02/11/2011 17:05, Jeremy Ashkenas a écrit : > 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. 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 accessed. 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 provides. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
