On Apr 6, 2008, at 3:06 AM, Nathan de Vries wrote: > I'm not denying that the problems you're trying to fix aren't > problems, it's just that I believe a wholesale locking down of the > language will be too drastic and may result in a shift away from the > language Javascripters have come to know and love.
You're doing it again: "wholesale locking down" is false as a general statement, and almost entirely false broken down into particulars. Are we "locking down" objects created by operator new applied to a function, or to the built-in Object, Array, String, Number, Boolean, Date, RegExp, and *Error constructors? No. Are we "locking down" objects created by initialisers? No (but we are using the original values of the Object and Array bindings, even in ES3 implementations today including Firefox 3, to preserve integrity for defense in depth, against JSON hijacking attacks). Are we "locking down" classes, new in ES4, so that their prototypes cannot be extended? No. Are we "locking down" classes so that their prototype-declared methods can't be overridden? No. Are we "locking down" classes against instance extension via ad-hoc property assignment? Yes, unless you use the 'dynamic' modifier in front of 'class'. Is this one last "Yes" therefore "wholesale"? Obviously not. Since you grant use-cases for sealing objects against mutation, are you simply arguing about what the default should be (that 'dynamic class' should not be required to get an extensible-instance factory, that 'class' should do that)? > Do you get the feeling that the majority of developers who aren't > writing the Javascript you're talking about will be left with a new > language that doesn't fit their development profile? No, because as noted above and copiously documented, ES4 is a superset of ES3. I expect "JS hackers" to continue doing what they have been doing, with newcomers choosing from a larger toolbelt and set of styles. We're opening up pathways for evolution that are either closed or clogged by high-cost barriers in ES3. > Do you think > that the developers who will write large-scale Javascript will cater > to those who are used to a more traditional approach? Which tradition do you mean? There are several. That most Ajax libraries reinvent classical OOP, sometimes with bugs and always with inefficiencies in code size, runtime, and memory use, and with integrity holes, suggests that common traditional approaches could be improved. This we are proposing to do in ES4. > My gut feeling to those two questions are "yes" and "no", but > unfortunately that's all it is; a gut feeling. I think assertions about "wholesale locking down" reflect feeling trumping analysis. I hope the Q&A above helps you see that "wholesale" is false. If we should argue about the default extensibility of instances created by unmodified class definitions, let's do that. If this is about other syntax choices, we can argue about those too, but with specifics, not vague generalities or angst. If anyone thinks the missing integrity property support (readonly, don't-delete, inextensible, not shadowable/overrideable, etc.) can be dispensed with, I've yet to hear a coherent claim to that effect. Adding minimal metaprogramming functions to mutate existing ES3 structures to enforce some of these properties is not enough, unless you take the performance hit, close the "in the middle of construction" integrity holes, and sugar it all with a code generator or macro system (we have code generators, but they cost enough that people avoid them and code to the JS metal; we don't have macros yet). Classes are an integrity device, for programming in the large as much as for defense against malicious code. There are other such measures in ES4, e.g. types, fixtures, and const. These fill gaps in ES3 that can't be faked. It seems to me the way forward is to make specific arguments about these proposals, not generalize inaccurately about their being "wholesale" in effect (they aren't), or untraditional (to the extent that JS authors today try to fake it, they are not). /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
