Fwd: ES3.1 Proposal Working Draft

Mark S. Miller erights at google.com
Wed Feb 20 12:12:19 PST 2008


[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080220/d1215c78/attachment-0002.html 


More information about the Es4-discuss mailing list