On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
ES3.1 is premised on accepting these dynamics, being originally
conceived as "ES3 + reality".
I have heard this repeated many times.
I heard it first with you and Maciej in the room, at Google, at the
January 2008 TC39 meeting. I'm not sure who said it, but it was part
of a committee-wide conversation about avoiding mission creep --
something I specifically recall you said you would help the committee
strive to avoid.
The July deadline of that era, the choice of specification based on
ES3's untestable pseudo-code and prose, and the minor version number
all make sense only in a limited-scope iteration on an "ES3 +reality"
mission.
Since January, the mission may have changed a bit but it cannot be as
open-ended as the goal statements you cite.
- Add commonly implemented and used extensions to the standard
(specifically most JavaScript 1.6 and 1.7 features)
I think these are what Maciej and others at that January meeting meant
by "reality".
Nevertheless, you're right that 3.1 did grow beyond that. The big
growth spurt, starting in April, was in the Object meta-programming
methods. I remember talking to Allen about these at the mid-April
Newton ES4 WG meeting.
The Object meta-programming suite is good stuff, necessary for getters
and setters and a lot more, including aspects of Harmony. No argument:
this goes beyond "ES3 + reality" -- but it happend after that January
meeting where the phrase was used.
I'm afraid the goals you list are too vague to shed light on what's in
ES3.1 vs. out (out meaning for ES4 then, for Harmony since the
summer). Too much broad motherhood and apple pie, too little to help
make crucial in vs. out decisions.
How about this concrete list instead? If we number the goals, we could
stick their numbers next to each letter-bulleted feature and probably
then revise the goals to be tighter:
A. ES3
B. Errata from Mozilla, others
C. Indirect eval agreements and similar
D. Array extras (map, filter, etc.)
E. JSON
F. getters and setters
G. Object.* meta-programming
H. Strict mode
I. Decimal
So while A-F are indeed "ES3 + reality", I agree that G and H add
enough that we can give "ES3 + reality" a rest. :-)
I am still unsure of whether item I fits in ES3.1, but Decimal is
being implemented in SpiderMonkey, which is the right order of work
for adding something like decimal arithmetic in my book:
implementation for user testing, concurrent or later spec drafting,
then spec finalization.
Given the progress Sam has made, Decimal may have more available/open-
source implementation and large-scale user experience than anything
else truly new (i.e., not JSON) in ES3.1. It will be hard for the
committee to reject if that happens!
Let me know if I've overlooked comparable items.
Having agreed to avoid "ES3 + reality", I have to say: broad and high-
level goals do not help scope ES3.1.
More, I think Maciej is on target in stressing the dynamics of web
interoperation and browser competition, which Neil Mix wrote about
previously, because those dynamics override many other considerations
that might be seen as flowing from the (too-)high-level goals.
And time is still of the essence, which must mean no open-ended
process of enlargement -- rather, concentrated work on a same-size or
even-smaller-than-current-draft spec.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
