[Maciej's latest message is a continuation of the following thread. I have removed email addresses from the correspondence below to avoid helping spammers. This conversation took place on e-TC39 -at- ecma-international.org ]
Forwarded conversation Subject: ES3.1 Proposal Working Draft ------------------------ From: *Kris Zyp* Date: Feb 20, 2008 9:22 AM I have been going through ES3.1 working draft and making some comments and additions. However, one of the issues is rather broad. From what I understand (and hope), ES3.1 is supposed to forward compatible with ES4, but it appears there are a large number of violations of this principle in the ES3.1 Proposal Working Draft. These include: - Secure Eval - (I commented on the page more specifics) - Targeted additions - (I commented on the page more specifics) - typeOf - Doesn't exist in ES4 - richer reflection - Doesn't exist in ES4 (that I am aware of) - arguments as Array - Simply needs to be corrected per Lars's comments. - Deprecation section - These don't cite any ES4 deprecations, so I am not sure if these are really deprecated in ES4 (which is a requirement for deprecation in ES3.1) I also added Getters and Setters and Destructuring Assignment sections as we believe these are very high priority additions for ES3.1. Thanks, Kris ---------- From: *Mark S. Miller* Date: Feb 20, 2008 9:30 AM I'm confused. Doesn't this violate the "no new syntax in ES3.1" design rule? -- Cheers, --MarkM ---------- From: *Kris Zyp* Date: Feb 20, 2008 9:36 AM Indeed you are right. Is this really a core value of 3.1 to be preserved? It is quite possible for non-syntactical changes to have a larger impact than syntactical changes. Syntax seems like a very arbitrary rule for deciding on inclusion of additions. Kris ---------- From: *Mark S. Miller* Date: Feb 20, 2008 10:18 AM It is arbitrary. I would be happy to replace it with another non- or less-arbitrary rule if we can quickly agree on one. But if we rely only on our taste for minimalism, then how do we guard against the following dynamic that I call "The Tragedy of the Common Lisp": Each of us has some pet addition we think would be a great addition to the language. "const", "decimal", getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. When arguing about any one of these by itself in the absence of a rule, each of us individually cares more to see our pet feature adopted than to prevent someone else's particular pet feature from being adopted. This is one of the reasons design by committee often goes bad. Only by adopting some rule do we raise the stakes. We all know that to agree to a feature that would violate the rule is to set a bad precedent and let open the floodgates of featuritis. Language design should be more like writing a sonnet and less like writing a phone book. Again, shouldn't we be having this discussion on es4-discuss? -- Cheers, --MarkM ---------- From: *Kris Zyp* Date: Feb 20, 2008 10:35 AM I understand, although I think it is difficult to come up with a reasonable succint rule that can be applied effectively, when each feature addition is really an ROI decision. We probably come up with a myriad of useless features for any given rule. We may just need to be very stingy in our ROI evaluation. On the otherhand, one rule that I think may be very valuable, is limiting to prior implementation. Prior implementation precedence does provides a very finite, limited set of possible features to choose from, and these features are of extra value since they improve cross-browser interoperability and therefore have accelerated adoption opportunity. They also have benefitted from real-world testing. I am not insisting on a strict following of this rule, but I do think it could be a very useful rule and definitely keep the features to a small set. There are also a number of features in the current working draft that could be omitted on the basis of this rule (typeOf, reflection, tail recursion, etc). I will let someone else make that call, definitely a much larger mailing list :). Kris ---------- From: *Maciej Stachowiak* Date: Feb 20, 2008 10:41 AM "No new syntax" actually does create a meaningful benefit, which is ability to do graceful degradation in browsers that don't support the new language. New builtin types, properties and methods can be tested for from script before using it, but new syntax can't since the presence of it alone will cause a syntax error at parse time. So it is less arbitrary than some other possible rules. Regards, Maciej ---------- From: *Mark S. Miller* Date: Feb 20, 2008 10:54 AM Ok, would anyone here mind if I forward the conversation so far to es4-discuss? -- Cheers, --MarkM ---------- From: *Kris Zyp* Date: Feb 20, 2008 10:54 AM True in the immediate future, but there will be a reverse effect down the road. At some (hopefully) ES3.1 and higher will be pervasive enough that devs just use it without detection, and only some browsers will support ES4. At this point having syntax already in ES3.1 means the syntax can be used, and the methods/properties that we deferred to ES4 can be detected and used optionally. At this point in the future, syntax that we don't include won't be useful for the reason you mention, but properties/methods we don't include, can be detected and optionally used. Kris ---------- From: *Maciej Stachowiak* Date: Feb 20, 2008 11:53 AM I am all for moving the discussion to es4-discuss. - Maciej ---------- From: *Maciej Stachowiak* Date: Feb 20, 2008 11:54 AM For information of those who might not be subscribed there yet, I'll reply on es4-discuss. - Maciej -- Cheers, --MarkM
_______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
