Proposed change to typeof

Brendan Eich brendan at mozilla.com
Wed Nov 5 22:26:05 PST 2008


On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:

> On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com>  
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081105/d9659092/attachment.html>


More information about the Es-discuss mailing list