Fwd: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Chris Pine-2]

Maciej Stachowiak wrote:

> Can anyone address feasibility of a small full implementation (source  
> code all the way to execution)?

If we didn't think it was feasible, we wouldn't be here.  :)  While we
don't have a full implementation yet (no one does), progress is looking
good.  Our latest engine, just out in Opera 9.5 beta, is both smaller
and considerably faster than our previous engine (which we've shipped on
many small devices).  It runs on devices smaller than an iPhone, no
problem.  (How much ram does an iPhone have?  I don't see that on
Apple's site.)

Chris Pine
Opera Software
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Thomas Reilly]

Its the es4 "discuss" list, I think the "technical discussion only" is
probably overly restrictive, there's lots of subjective judgements
involved in evaluating languages.   We just want to hear workable
feedback and "it has too many features" or it has many good features
that won't work well together isn't particularly helpful.   What
features would you drop?   What problems arise when exactly which
features are combined?  

Why do you think Java 1.5 is worse than 1.4?  That may be relevant given
the overlap between the languages.  We write a lot of Java around here
and we generally prefer 1.5.  Our ActionScript3 compiler is written in
1.5 even though to meet our customers needs we had to write a class file
"downgrader" to be able to run the compiler on older jvms.  We also use
a lot of python and that's probably evident in ES4, personally I wish
ES4 could have the indent scoping feature but that got shot down long
ago.

So don't feel limited to technical discussions, just help us out by
adding some meat to your criticisms.  It would also help if you could
get all the extremely good programming language folks you met with at
OOPSLA who hate ES4 and feel they are being oppressed by this runaway
train wreck of a standards process to voice their concerns.  Sounds
horrific!  Can't imagine how those feelings got scared up ;-)  Well its
good that people care, they should, but obviously we don't want to steam
roll anyone and would like to hear from them, oppressed or otherwise.

-----Original Message-----
From: es4-discuss-bounces@...
[mailto:es4-discuss-bounces@...] On Behalf Of Mark Miller
Sent: Tuesday, October 30, 2007 10:49 AM
To: Chris Pine
Cc: zwetan; es4-discuss@...
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007 10:13 AM, Chris Pine <chrispi@...> wrote:

> Yes, I read that.  I am extremely doubtful that Microsoft is suddenly
> so concerned about browser compatibility for the benefit of the web.  
> (When IE passes the Acid 2 test, let's talk again.)
>
> It's nice that MS has constructed this document identifying browser
> differences.  But frankly, this is too little, too late.  We are
> painfully aware of the significant differences.  Suggesting that we
> all sit down and strive to fix every last trivial discrepancy under
> the guise of "browser compatibility" is manipulative and, from a
> business standpoint, absurd.  It is an unnecessary task that would
> never be completed.
>
> In essence, it is just another stalling tactic.

When I raised non-technical points critical of the ES4 proposal, people
rightly shot back with a "technical discussion only!" response, which
I've respected. Since then, most of the traffic on the list has been
non-technical criticisms of the critics of the ES4 proposal. Much of
this traffic, such as the message I quote above, continues to speculate
about the motives of others, rather than engaging with what they are
saying. My comments, which provoked so much response, contained no such
speculation. I can only conclude that, on this list, the injunction
"technical discussion only!" should be interpreted as carrying the
additional clause "unless you agree with us."


--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Oct 30, 2007, at 1:01 PM, Chris Pine wrote:

> Maciej Stachowiak wrote:
>
>> Can anyone address feasibility of a small full implementation  
>> (source  code all the way to execution)?
>
> If we didn't think it was feasible, we wouldn't be here.  :)  While  
> we don't have a full implementation yet (no one does), progress is  
> looking good.  Our latest engine, just out in Opera 9.5 beta, is  
> both smaller and considerably faster than our previous engine (which  
> we've shipped on many small devices).  It runs on devices smaller  
> than an iPhone, no problem.  (How much ram does an iPhone have?  I  
> don't see that on Apple's site.)

Does your latest shipping engine implement parts of ES4? If so, how  
much?

By the way, I think the discussions about language size could benefit  
from some quantitative data. I think the following comparisons would  
be interesting:

1) Size of the ES4 grammar relative to the ES3 grammar (say, by count  
of productions).

2) Size of the ES4 standard library by count of classes, methods and  
properties.

I am willing to run the number on these if someone can help me find  
the grammar and some sort of standard library index in the spec.

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Thomas Reilly]

http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/

I've heard its got 128MB with 11mb of memory reserved for the display,
add 620 mghz processor, 8 GB disk, fp and integer SIMD units.  Does this
still qualify as an embedded device?  It probably sports virtual memory
for cying out loud (backed up by claims of a native SDK on the horizon).
Personally I think they should lose to java coprocessor and add more
cache.

The iphone could probably run a poorly written, bloated, interpreted ES4
implementation well enough to run most web pages.

-----Original Message-----
From: es4-discuss-bounces@...
[mailto:es4-discuss-bounces@...] On Behalf Of Chris Pine
Sent: Tuesday, October 30, 2007 1:02 PM
To: Maciej Stachowiak
Cc: Steven Johnson; es4-discuss
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Maciej Stachowiak wrote:

> Can anyone address feasibility of a small full implementation (source
> code all the way to execution)?

If we didn't think it was feasible, we wouldn't be here.  :)  While we
don't have a full implementation yet (no one does), progress is looking
good.  Our latest engine, just out in Opera 9.5 beta, is both smaller
and considerably faster than our previous engine (which we've shipped on
many small devices).  It runs on devices smaller than an iPhone, no
problem.  (How much ram does an iPhone have?  I don't see that on
Apple's site.)

Chris Pine
Opera Software
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Jeff Dyer]

On 10/30/07 1:23 PM, Maciej Stachowiak wrote:

>
> On Oct 30, 2007, at 1:01 PM, Chris Pine wrote:
>
>> Maciej Stachowiak wrote:
>>
>>> Can anyone address feasibility of a small full implementation
>>> (source  code all the way to execution)?
>>
>> If we didn't think it was feasible, we wouldn't be here.  :)  While
>> we don't have a full implementation yet (no one does), progress is
>> looking good.  Our latest engine, just out in Opera 9.5 beta, is
>> both smaller and considerably faster than our previous engine (which
>> we've shipped on many small devices).  It runs on devices smaller
>> than an iPhone, no problem.  (How much ram does an iPhone have?  I
>> don't see that on Apple's site.)
>
> Does your latest shipping engine implement parts of ES4? If so, how
> much?
>
> By the way, I think the discussions about language size could benefit
> from some quantitative data. I think the following comparisons would
> be interesting:
>
> 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count
> of productions).
>
> 2) Size of the ES4 standard library by count of classes, methods and
> properties.
>
> I am willing to run the number on these if someone can help me find
> the grammar and some sort of standard library index in the spec.

The grammar is posted at:

  http://ecmacript.org/es4/spec/grammar.pdf

The builtin's are described in the a draft library spec in the monotone
repository (./spec/library.pdf), which you should have access to.

Another interesting comparison is between ES3 and ES4 asts. There is a lot
of syntactic sugar that get boiled out during parsing of ES4 programs. In
fact, the same parse routines can be reused for different productions of the
surface grammar. Compare the value syntax for objects and type syntax for
record types, for example.

I'm happy to help put either document in a format that is easier to analyze.

Jd

> Regards,
> Maciej
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Oct 30, 2007, at 1:45 PM, Thomas Reilly wrote:

>
> http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/
>
> I've heard its got 128MB with 11mb of memory reserved for the display,
> add 620 mghz processor, 8 GB disk, fp and integer SIMD units.  Does  
> this
> still qualify as an embedded device?  It probably sports virtual  
> memory
> for cying out loud (backed up by claims of a native SDK on the  
> horizon).
> Personally I think they should lose to java coprocessor and add more
> cache.
>
> The iphone could probably run a poorly written, bloated, interpreted  
> ES4
> implementation well enough to run most web pages.

I can't talk about the details of the iPhone's hardware but I can tell  
you that iPhone and iPod touch do not have room for significantly more  
runtime memory use or code footprint. Getting WebKit (pretty small for  
a browser engine) to run was hardly a cakewalk.

In any case, I'm not trying to spread FUD here. I'd honestly like to  
get some estimates of language size and implementability. I'm going to  
put my money where my mouth is and do the counts I suggested.

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Jeff Dyer]

Fixed url of grammar.


On 10/30/07 1:46 PM, Jeff Dyer wrote:

>
>
>
> On 10/30/07 1:23 PM, Maciej Stachowiak wrote:
>
>>
>> On Oct 30, 2007, at 1:01 PM, Chris Pine wrote:
>>
>>> Maciej Stachowiak wrote:
>>>
>>>> Can anyone address feasibility of a small full implementation
>>>> (source  code all the way to execution)?
>>>
>>> If we didn't think it was feasible, we wouldn't be here.  :)  While
>>> we don't have a full implementation yet (no one does), progress is
>>> looking good.  Our latest engine, just out in Opera 9.5 beta, is
>>> both smaller and considerably faster than our previous engine (which
>>> we've shipped on many small devices).  It runs on devices smaller
>>> than an iPhone, no problem.  (How much ram does an iPhone have?  I
>>> don't see that on Apple's site.)
>>
>> Does your latest shipping engine implement parts of ES4? If so, how
>> much?
>>
>> By the way, I think the discussions about language size could benefit
>> from some quantitative data. I think the following comparisons would
>> be interesting:
>>
>> 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count
>> of productions).
>>
>> 2) Size of the ES4 standard library by count of classes, methods and
>> properties.
>>
>> I am willing to run the number on these if someone can help me find
>> the grammar and some sort of standard library index in the spec.
>
> The grammar is posted at:
>
>   http://ecmascript.org/es4/spec/grammar.pdf
>
> The builtin's are described in the a draft library spec in the monotone
> repository (./spec/library.pdf), which you should have access to.
>
> Another interesting comparison is between ES3 and ES4 asts. There is a lot
> of syntactic sugar that get boiled out during parsing of ES4 programs. In
> fact, the same parse routines can be reused for different productions of the
> surface grammar. Compare the value syntax for objects and type syntax for
> record types, for example.
>
> I'm happy to help put either document in a format that is easier to analyze.
>
> Jd
>
>> Regards,
>> Maciej
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss@...
>> https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

[Kris asks legitimate questions, to be answered by more than a Microsoft spokesperson. I'm going to reply cc'ing the list, even though there are political points here along with technical content. The list is for discussion of ES4, and that category looks like it must include some political discussion.

 Also, this reply is LONG. Sorry, I've tried to compress without doing anyone an injustice.

 Skip if you want to avoid any political content. If you think I'm FUDding or attacking individuals unfairly, call me on it -- with specific quotations if possible. If I'm out of line, I'll apologize  to the list and amend my words. If we simply disagree on the fundamental substance, that's good to know too.

 I'm trying to shed some light on what has clearly been too much of a dark-room standards process, excluding the materials we've exported at http://ecmascript.org/. 

/be]

On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote:

From a pragmatic perspective, it seems to that the critical goal behind all of this, is what will bring a better development environment for the future of the web, and the key to this is what will be broadly implemented. The choice of the name is of course around this central issue since the ES title brings such a strong motivitation for implementation. However, if ~10 years

Try two years -- ten is way, way too long for developers to wait, and anyway beyond any credible crystal ball's range. The proprietary stacks from Microsoft and Adobe won't wait that long for competition from browser-based web standards, as Doug Crockford and others warn; they'll propagate all over the web well before ten years.

down the road, ES4 is not implemented broadly enough that web developers can code to it, than it is of signficantly less value. While unanimity is not needed for a standard to be passed, if the one of the key browser vendors will not implement it, than how valuable are our efforts?

Let's find out, by having a standard that browsers and plugins can choose to implement for interoperability and shared developer knowledge. Enough companies want ES4 as a standard that (absent technical problems), it ought to become one, whether or not all browser vendors buy into it.

If you give all the power over standardization to any one company, then you are that company's slave, and I predict you'll get treated accordingly. This happened once already, after IE achieved a virtual monopoly. Just consider all the unfixed JScript bugs, many dating to IE4, still in IE7.

 I know that there are, or will be efforts to provide a Tamarin plugin for other browsers, but is this really what we are pinning our hope on?

Not necessarily, but (hey, I came up with it ;-) it's not a bad plan absent competitive pressure on Microsoft to support ES4 in IE.

You may not know this, but minority-share browsers do not have as low market share as the Comscore and WebSideStory analytics firms' results show in aggregate for the U.S.. At high value sites, visited more frequently by "lead users" and otherwise influential (and better-monetized) visitors, Firefox, Safari, and Opera do better -- sometimes much better. If you look at Xiti's results for Europe, Firefox is trending to cross the 50% market-share line in some countries.

Whatever you do, never give up your own sovereignty as a browser user or a web developer to a dominant player. You always have a choice.

Plugins usually don't reach necessary distribution for developers to rely on them.

Counterexample: the Flash Player.

I have no idea whether Flash would ship ScreamingMonkey support. I certainly hope so, given Microsoft's rejection since early this year of ES4.

Or are we hoping that the ES4 title will be sufficient to get an implementation from every vendor?

Title, schmitle. :-) The "brand value" of ES4 may be an issue for browser vendors, but it is not the main issue for developers, and users don't know or care. What matters is whether web developers can effectively demand, and count, on near ubiquity and quality from ES4 implementations, soon (a year or two). That is an open question, as noted above -- and there are several reasons to have hope.

I certainly acknowledge that it is insidious that there might a suggestion to design around one member, but I will still ask, is there any concessions that can be made to increase the probability that MS would implement ES4 in the future?

No. Without speaking for anyone else, I am now going to give more information about what has already been said inside TG1, since the TG1 dispute has already spilled out into the blogosphere since last week's Ajax Experience East, when as part of a panel discussion, Doug Crockford made some statements about TG1 members and motives. Others in TG1 can back this up, and anyone can check our meeting minutes, which are public at http://wiki.ecmascript.org/ with complete revision histories.

While at certain times, as in late 2006 and before March 2007, Microsoft talked in TG1 (or possibly just to me) about perhaps standardizing JS1.7 in Firefox 2, at other times we have heard a very clear "No" to the question of substantive changes from ES3 like those in Firefox: No JS1.7 extensions, no change from ES3 apart from deprecations and maintenance.

IIRC, you yourself heard a "No" in reply to your "JS1.7 features coming in IE?" face-to-face question posed to Chris Wilson at The Ajax Experience West this summer (I happened to be nearby at the time). I recall seeing some back-peddling to avoid committing either way in a comment from Chris at http://ajaxian.com after that, but you tell me: do you really expect anything more, given statements such as Allen Wirfs-Brock's comment at Ric Johnson's OpenAjax blog, and the content available at the JScript blog?

Sure, a Microsoft "vision" for JScript will be rolled out, real soon now. Based on everything we've heard in TG1, it is safe to say that the vision is either a fork of ES3 away from ES4, or a lot of do-nothing posturing about maintenance and safeguarding compatibility, to give Silverlight and WPF time to penetrate the Web. I would love to be proven wrong -- c'mon, Microsoft, make me eat my words (happily): embrace (and extend, for all I care) ES4. Just get the mandatory core language right, as in, far fewer overt bugs than JScript vs. ES3.

Perhaps this has already been discussed, so I apologize if it has. Does MS have specific issues, or is their dissent simply for the purpose of avoiding committing to implementation (regardless of the content of ES4)? Is security one of the main issues? Is it the size and scope of the language? From what I understand, I think these are Crockford's concerns, although I don't know if that is true for MS.

One at a time:

* Not only the majority of TG1, but many on this list, have asked for specific technical objections, and received none in reply. Even a summary technical judgment against ES4 in full needs to be decomposable into smaller technical arguments. ES4 needs to be fully specified and implemented, for sure, so we're not claiming it is done or proven yet. But disproof that disqualifies it as a candidate successor edition needs to be demonstrated.

On a positive note, I will say this: as a working group, when we have not been wearing political armor, we've had productive technical dialogs about proposed ES4 features and their progenitors in the literature, especially with Allen Wirfs-Brock. But the Microsoft position (so-called -- it's clear when Allen is speaking for Microsoft, which is a good thing!) has not consisted of detailed analysis and conclusions against specific technical features. It has simply been a summary judgment expressed as "Microsoft opposes ES4" and (memorably, from April) "the web doesn't need to change much".

* The browser profile I cited above, started by Pratap Lakshman of Microsoft, was superseded by an ES3.1 proposal, which was made following an agreement at the March TG1 meeting. At that meeting, it was also agreed that any ES3.1 would be implemented as a subset of the ES4 reference implementation (for testability) This has not happened.

Everyone also agreed at the March meeting that ES3.1 would not be approved by TG1 until it could be evaluated for forward and backward compatibility. Finally, I recorded an agreement at least among the majority of TG1 that ES3.1 was not approved of as a standard-to-be, but was something the majority thought could be explored further by the minority group, under TG1's charter from TC39.

Note that the "3.1" name does not work in Ecma terms. There is no minor edition process in Ecma (mozilla.org has hosted the only errata page), so if ES3.1 were standardized as a successor to ES3, it would be renamed the 4th Edition. This obviously would create conflict in TG1 and confusion in the market.

* ES3.1 was superseded by no substantive work  in the es3.1 section of the wiki since April. Instead, two documents describing JScript (one about the @if/@else/@endif preprocessor (PDF), the other about JScript deviations from ES3), have been produced by Pratap. These are informative, but not even potentially normative as written, except where browser implementations have already matched JScript (in order to gain market share by interoperating) -- and ES4 already contains such bug fixes to ES3.

* Security is an "issue" (not in the Oprah sense), all right. A bit more precisely, it is a set of end-to-end properties that need solid enforcement mechanisms at many layers of abstraction. Security is however not a unitary good or "product". You sometimes hear demands for TG1, or all browser vendors, to stop the world and work on security. That is an unrealistic demand; the world doesn't work that way.

We've talked a bit in TG1 about security properties, mainly Integrity and Confidentiality. Apart from making ES4 statically checkable and improving binding forms to reduce mutation hazards, we are not biting off riskier work. The academic research is not solid yet (unlike the research on multimethods, for example). There is no good way that anyone involved in TG1 can see, in the core ECMAScript language only, to standardize a capability system for the web.

It's clear from experience from Mozilla and many security researchers that even a posteriori mashups built on a capability system will leak information. So information flow type systems could be explored, but again the research on hybrid techniques that do not require a priori maximum-authority judgments, which do not work on the web (think mashups in the browser without the user having to click "OK" to get rid of a dialog), simply is not there yet. Mashups are unplanned, emergent. Users click "OK" when they shouldn't. These are hard, multi-disciplinary research problems.

Experiments such as Google Caja are interesting (discussion here), and Mark Miller will (I hope) smite me mightily if I misspeak about it, but as far as I can tell, such systems create an incompatible subset of JS into which developers may "opt" -- not a successor standard for the ECMAScript language that is backward compatible. Such a subset could be a very good thing, don't get me wrong. But it does not fall neatly under TG1's charter, because it's not backward-compatible, and profiled standards are considered harmful.

Anyway, it's early days for Caja and other such systems. If TG1 continues to function, it should definitely harvest good ideas from it, and stand on shoulders, not toes.

We've pressed Doug Crockford on this point and heard nothing in the way of concrete proposals, save for a small one I championed at the last face-to-face meeting (a better-isolated String.prototype.evaluate() taking a scope object). But that went nowhere for lack of effort -- I half expect it to turn up in "Microsoft's vision for ECMAScript", which would make a fork in the standard. I'll still try to rescue it for ES4, but it's just a small isolation device, good to have, but not nearly enough for "Security" with a capital S.

I hope to hear more from Doug and others as things evolve, but ideas like a capability-based message-passing architecture built on Google Gears, which Doug proposed at a talk given at Google recently, do not fit in ES4's schedule and mandate to avoid premature standardization. ES4 is not about to normatively specify Google Gears APIs, which only came out this past spring. Gears APIs  for workerpools are a great idea, but they are out of scope for the core language, which has not only an apparently single-thread execution model, but one-thread-only and even zero-OS implementations.

APIs such as those purveyed by Gears should be standardized in the WHAT-WG and/or the W3C (and I've seen some WHAT-WG standardization work on Gears already).

I think that if even 25% subset of ES4 was uniformly implemented in all browsers in 10 years, web developers would be vastly further along than if the 100% of ES4 was implemented in half the browsers.

You're kidding, right? Ten years is far too long, and there's no coherent 25% -- a lot of ES4 depends on the type system. Would you cut that and try to stitch the remaining pieces back together? King Solomon only offered to bisect a child to find the true mother. Quartering was not a good idea even for that purpose. Anyway, Microsoft is now the avowed anti-mother of ES4, so you are only going to help mutilate or kill ES4 with this kind of bargaining.

To switch metaphors to something less biblical, gory, and humorless: given the on-again/off-again flirtation with JS1.7 compatibility by Microsoft in TG1, I would not be surprised if you got a little foot-bumping under the table. But take it from me, they are teasing. ;-)

While unfortunate that such orthogonal issues could affect language design, and perhaps stifle innovation, I would like to see what will be best for the future of the web.

Does anybody know if there is anything that can be done to increase the likelood of full cross browser implementation of ES4? Does anyone know the issues or parts of ES4 that are causing dissent? Is it the impact of the size of the language (on security, implementability, etc)?

Apologies for my excessive pragmatism,

I don't think you are being pragmatic. I think you are making yourself too much of a victim :-], seemingly giving all power to the dominant player and hoping for some scraps from the table. Pragmatism means using the tools you have and looking out for your own interests, even if it is scary, or requires some risk in the short run.

For me, pragmatism means ES4 as a standard that any browser can interoperably implement and deploy, with ScreamingMonkey for browsers that don't like ES4.

The world can change. Before Firefox, there was no hope. Who knew in 2002 or 2003 that we would be having an exchange like this one, within (my best prediction) a year or two of ES4 support rolling out, possibly to the majority of browsers? To quote from a great movie: Never give up, never surrender! ;-)

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Kris Zyp-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Brendan,

Thank you for the thorough and even somewhat inspiring response, that certainly helps me (and hopefully others) to understand the situation better. I may a have few other questions later, but for now, Thank you!

Kris

 

On 10/30/07, Brendan Eich <brendan@...> wrote:

[Kris asks legitimate questions, to be answered by more than a Microsoft spokesperson. I'm going to reply cc'ing the list, even though there are political points here along with technical content. The list is for discussion of ES4, and that category looks like it must include some political discussion.

 

 Also, this reply is LONG. Sorry, I've tried to compress without doing anyone an injustice.

 

 Skip if you want to avoid any political content. If you think I'm FUDding or attacking individuals unfairly, call me on it -- with specific quotations if possible. If I'm out of line, I'll apologize  to the list and amend my words. If we simply disagree on the fundamental substance, that's good to know too.

 

 I'm trying to shed some light on what has clearly been too much of a dark-room standards process, excluding the materials we've exported at http://ecmascript.org/. 

 

/be]

 

On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote:

From a pragmatic perspective, it seems to that the critical goal behind all of this, is what will bring a better development environment for the future of the web, and the key to this is what will be broadly implemented. The choice of the name is of course around this central issue since the ES title brings such a strong motivitation for implementation. However, if ~10 years
 

 

Try two years -- ten is way, way too long for developers to wait, and anyway beyond any credible crystal ball's range. The proprietary stacks from Microsoft and Adobe won't wait that long for competition from browser-based web standards, as Doug Crockford and others warn; they'll propagate all over the web well before ten years.

down the road, ES4 is not implemented broadly enough that web developers can code to it, than it is of signficantly less value. While unanimity is not needed for a standard to be passed, if the one of the key browser vendors will not implement it, than how valuable are our efforts?
 

 

Let's find out, by having a standard that browsers and plugins can choose to implement for interoperability and shared developer knowledge. Enough companies want ES4 as a standard that (absent technical problems), it ought to become one, whether or not all browser vendors buy into it.

 

If you give all the power over standardization to any one company, then you are that company's slave, and I predict you'll get treated accordingly. This happened once already, after IE achieved a virtual monopoly. Just consider all the unfixed JScript bugs, many dating to IE4, still in IE7.

 

 I know that there are, or will be efforts to provide a Tamarin plugin for other browsers, but is this really what we are pinning our hope on?
 

 

Not necessarily, but (hey, I came up with it  ;-) it's not a bad plan absent competitive pressure on Microsoft to support ES4 in IE.

 

You may not know this, but minority-share browsers do not have as low market share as the Comscore and WebSideStory analytics firms' results show in aggregate for the U.S.. At high value sites, visited more frequently by "lead users" and otherwise influential (and better-monetized) visitors, Firefox, Safari, and Opera do better -- sometimes much better. If you look at  Xiti's results for Europe, Firefox is trending to cross the 50% market-share line in some countries.

 

Whatever you do, never give up your own sovereignty as a browser user or a web developer to a dominant player. You always have a choice.

Plugins usually don't reach necessary distribution for developers to rely on them.
 

 

Counterexample: the Flash Player.

 

I have no idea whether Flash would ship ScreamingMonkey support. I certainly hope so, given Microsoft's rejection since early this year of ES4.

Or are we hoping that the ES4 title will be sufficient to get an implementation from every vendor?
 

 

Title, schmitle. :-) The "brand value" of ES4 may be an issue for browser vendors, but it is not the main issue for developers, and users don't know or care. What matters is whether web developers can effectively demand, and count, on near ubiquity and quality from ES4 implementations, soon (a year or two). That is an open question, as noted above -- and there are several reasons to have hope.

I certainly acknowledge that it is insidious that there might a suggestion to design around one member, but I will still ask, is there any concessions that can be made to increase the probability that MS would implement ES4 in the future?
 

 

No. Without speaking for anyone else, I am now going to give more information about what has already been said inside TG1, since the TG1 dispute has already spilled out into the blogosphere since last week's Ajax Experience East, when as part of a panel discussion, Doug Crockford made some statements about TG1 members and motives. Others in TG1 can back this up, and anyone can check our meeting minutes, which are public at http://wiki.ecmascript.org/ with complete revision histories.

 

While at certain times, as in late 2006 and before March 2007, Microsoft talked in TG1 (or possibly just to me) about perhaps standardizing  JS1.7 in Firefox 2, at other times we have heard a very clear "No" to the question of substantive changes from ES3 like those in Firefox: No JS1.7 extensions, no change from ES3 apart from deprecations and maintenance.

 

IIRC, you yourself heard a "No" in reply to your "JS1.7 features coming in IE?" face-to-face question posed to Chris Wilson at The Ajax Experience West this summer (I happened to be nearby at the time). I recall seeing some back-peddling to avoid committing either way in a comment from Chris at http://ajaxian.com after that, but you tell me: do you really expect anything more, given statements such as Allen Wirfs-Brock's comment at Ric Johnson's OpenAjax blog, and the content available at the  JScript blog?

 

Sure, a Microsoft "vision" for JScript will be rolled out, real soon now. Based on everything we've heard in TG1, it is safe to say that the vision is either a fork of ES3 away from ES4, or a lot of do-nothing posturing about maintenance and safeguarding compatibility, to give Silverlight and WPF time to penetrate the Web. I would love to be proven wrong -- c'mon, Microsoft, make me eat my words (happily): embrace (and extend, for all I care) ES4. Just get the mandatory core language right, as in, far fewer overt bugs than JScript vs. ES3.

Perhaps this has already been discussed, so I apologize if it has. Does MS have specific issues, or is their dissent simply for the purpose of avoiding committing to implementation (regardless of the content of ES4)? Is security one of the main issues? Is it the size and scope of the language? From what I understand, I think these are Crockford's concerns, although I don't know if that is true for MS.
 

 

One at a time:

 

* Not only the majority of TG1, but many on this list, have asked for specific technical objections, and received none in reply. Even a summary technical judgment against ES4 in full needs to be decomposable into smaller technical arguments. ES4 needs to be fully specified and implemented, for sure, so we're not claiming it is done or proven yet. But disproof that disqualifies it as a candidate successor edition needs to be demonstrated.

 

On a positive note, I will say this: as a working group, when we have not been wearing political armor, we've had productive technical dialogs about proposed ES4 features and their progenitors in the literature, especially with Allen Wirfs-Brock. But the Microsoft position (so-called -- it's clear when Allen is speaking for Microsoft, which is a good thing!) has not consisted of detailed analysis and conclusions against specific technical features. It has simply been a summary judgment expressed as "Microsoft opposes ES4" and (memorably, from April) "the web doesn't need to change much".

 

* The browser profile I cited above, started by Pratap Lakshman of Microsoft, was superseded by an  ES3.1 proposal, which was made following an agreement at the March TG1 meeting. At that meeting, it was also agreed that any ES3.1 would be implemented as a subset of the ES4 reference implementation (for testability) This has not happened.

 

Everyone also agreed at the March meeting that ES3.1 would not be approved by TG1 until it could be evaluated for forward and backward compatibility. Finally, I recorded an agreement at least among the majority of TG1 that ES3.1 was not approved of as a standard-to-be, but was something the majority thought could be explored further by the minority group, under TG1's charter from TC39.

 

Note that the "3.1" name does not work in Ecma terms. There is no minor edition process in Ecma (mozilla.org has hosted the only errata page), so if ES3.1 were standardized as a successor to ES3, it would be renamed the 4th Edition. This obviously would create conflict in TG1 and confusion in the market.

 

* ES3.1 was superseded by no substantive work  in the es3.1 section of the wiki since April. Instead, two documents describing JScript (one about the @if/@else/@endif preprocessor ( PDF), the other about  JScript deviations from ES3), have been produced by Pratap. These are informative, but not even potentially normative as written, except where browser implementations have already matched JScript (in order to gain market share by interoperating) -- and ES4 already contains such bug fixes to ES3.

 

* Security is an "issue" (not in the Oprah sense), all right. A bit more precisely, it is a set of end-to-end properties that need solid enforcement mechanisms at many layers of abstraction. Security is however not a unitary good or "product". You sometimes hear demands for TG1, or all browser vendors, to stop the world and work on security. That is an unrealistic demand; the world doesn't work that way.

 

We've talked a bit in TG1 about security properties, mainly Integrity and Confidentiality. Apart from making ES4 statically checkable and improving binding forms to reduce mutation hazards, we are not biting off riskier work. The academic research is not solid yet (unlike the research on multimethods, for example). There is no good way that anyone involved in TG1 can see, in the core ECMAScript language only, to standardize a capability system for the web.

 

It's clear from experience from Mozilla and many security researchers that even a posteriori mashups built on a capability system will leak information. So information flow type systems could be explored, but again the research on hybrid techniques that do not require a priori maximum-authority judgments, which do not work on the web (think mashups in the browser without the user having to click "OK" to get rid of a dialog), simply is not there yet. Mashups are unplanned, emergent. Users click "OK" when they shouldn't. These are hard, multi-disciplinary research problems.

 

Experiments such as Google Caja are interesting ( discussion here), and Mark Miller will (I hope) smite me mightily if I misspeak about it, but as far as I can tell, such systems create an incompatible subset of JS into which developers may "opt" -- not a successor standard for the ECMAScript language that is backward compatible. Such a subset could be a very good thing, don't get me wrong. But it does not fall neatly under TG1's charter, because it's not backward-compatible, and profiled standards are considered harmful.

 

Anyway, it's early days for Caja and other such systems. If TG1 continues to function, it should definitely harvest good ideas from it, and stand on shoulders, not toes.

 

We've pressed Doug Crockford on this point and heard nothing in the way of concrete proposals, save for a small one I championed at the last face-to-face meeting (a better-isolated String.prototype.evaluate() taking a scope object). But that went nowhere for lack of effort -- I half expect it to turn up in "Microsoft's vision for ECMAScript", which would make a fork in the standard. I'll still try to rescue it for ES4, but it's just a small isolation device, good to have, but not nearly enough for "Security" with a capital S.

 

I hope to hear more from Doug and others as things evolve, but ideas like a capability-based message-passing architecture built on Google Gears, which Doug proposed at a  talk given at Google recently, do not fit in ES4's schedule and mandate to avoid premature standardization. ES4 is not about to normatively specify Google Gears APIs, which only came out this past spring. Gears APIs  for  workerpools are a great idea, but they are out of scope for the core language, which has not only an apparently single-thread execution model, but one-thread-only and even zero-OS implementations.

 

APIs such as those purveyed by Gears should be standardized in the WHAT-WG and/or the W3C (and I've seen some WHAT-WG standardization work on Gears already).

I think that if even 25% subset of ES4 was uniformly implemented in all browsers in 10 years, web developers would be vastly further along than if the 100% of ES4 was implemented in half the browsers.
 

 

You're kidding, right? Ten years is far too long, and there's no coherent 25% -- a lot of ES4 depends on the type system. Would you cut that and try to stitch the remaining pieces back together? King Solomon only offered to bisect a child to find the true mother. Quartering was not a good idea even for that purpose. Anyway, Microsoft is now the avowed anti-mother of ES4, so you are only going to help mutilate or kill ES4 with this kind of bargaining.

 

To switch metaphors to something less biblical, gory, and humorless: given the on-again/off-again flirtation with JS1.7 compatibility by Microsoft in TG1, I would not be surprised if you got a little foot-bumping under the table. But take it from me, they are teasing. ;-)

While unfortunate that such orthogonal issues could affect language design, and perhaps stifle innovation, I would like to see what will be best for the future of the web.

Does anybody know if there is anything that can be done to increase the likelood of full cross browser implementation of ES4? Does anyone know the issues or parts of ES4 that are causing dissent? Is it the impact of the size of the language (on security, implementability, etc)?

Apologies for my excessive pragmatism,

 

I don't think you are being pragmatic. I think you are making yourself too much of a victim :-], seemingly giving all power to the dominant player and hoping for some scraps from the table. Pragmatism means using the tools you have and looking out for your own interests, even if it is scary, or requires some risk in the short run.

 

For me, pragmatism means ES4 as a standard that any browser can interoperably implement and deploy, with ScreamingMonkey for browsers that don't like ES4.

 

The world can change. Before Firefox, there was no hope. Who knew in 2002 or 2003 that we would be having an exchange like this one, within (my best prediction) a year or two of ES4 support rolling out, possibly to the majority of browsers? To quote from a great movie: Never give up, never surrender! ;-)

 

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Thomas Reilly]

I'm sure!  I wasn't being completely serious.  We've learned that when
you design something for the desktop its really hard to retrofit it for
smaller devices, much better to start out small and tweak it to take
advantage of the desktop's resource largesse.  We also find that it
almost never happens that way ;-)  Given that my MacBookPro's kernel
task is taking 200MB if my iphone is really running OS X then I'd say
the Apple engineers did some serious squeezing to get the OS and
applications/graphics all running in 128mb.

+1 on real language size/implementability discussions.   Nothing more
real, relevant and telling than having an es4 compiler written in es4
making use of as many language features as possible, luckily we're
working just such a thing.  How many lines of code is it?   How much
memory does it take to compile itself on the RI, on Tamarin?  How fast
can it compile itself?  How big is the resulting abc?

Sure we'll start out with poor #'s and we can't even answer some of the
questions but it'll be good to know where we're starting from.

I wish there was a language shootout page that tracked these metrics for
platforms/languages with self hosting compilers.  Does anyone have any
ancedotal data?  

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@...]
Sent: Tuesday, October 30, 2007 1:51 PM
To: Thomas Reilly
Cc: Chris Pine; Steven Johnson; es4-discuss
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM


On Oct 30, 2007, at 1:45 PM, Thomas Reilly wrote:

>
> http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/
>
> I've heard its got 128MB with 11mb of memory reserved for the display,

> add 620 mghz processor, 8 GB disk, fp and integer SIMD units.  Does
> this still qualify as an embedded device?  It probably sports virtual
> memory for cying out loud (backed up by claims of a native SDK on the
> horizon).
> Personally I think they should lose to java coprocessor and add more
> cache.
>
> The iphone could probably run a poorly written, bloated, interpreted
> ES4
> implementation well enough to run most web pages.

I can't talk about the details of the iPhone's hardware but I can tell
you that iPhone and iPod touch do not have room for significantly more
runtime memory use or code footprint. Getting WebKit (pretty small for a
browser engine) to run was hardly a cakewalk.

In any case, I'm not trying to spread FUD here. I'd honestly like to get
some estimates of language size and implementability. I'm going to put
my money where my mouth is and do the counts I suggested.

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark Miller-2]

On Oct 30, 2007 2:38 PM, Brendan Eich <brendan@...> wrote:

Experiments such as Google Caja are interesting ( discussion here), and Mark Miller will (I hope) smite me mightily if I misspeak about it, but as far as I can tell, such systems create an incompatible subset of JS into which developers may "opt" -- not a successor standard for the ECMAScript language that is backward compatible. Such a subset could be a very good thing, don't get me wrong. But it does not fall neatly under TG1's charter, because it's not backward-compatible, and profiled standards are considered harmful.

Hi Brendan,

Your summary may well be accurate. I'm just confused about a few points of terminology I hope you might clarify:

Caja is approximately a subset of ES3, much as JSON is a subset of ES3, and ES3 is approximately a subset of the ES4 proposal. ADsafe is also approximately a superset of JSON and a subset of ES3. We have yet to understand well (or decide) the degree to which ADsafe is a subset of Caja.

AFAIK, the only subset relationships here with unqualified compatibility are JSON < ES3 and JSON < proposed ES4. All the others have hazards that programmers need to understand in order to make use of the subset relationship. In this sense, the situation is analogous to C being approximately a subset of C++: When writing a correct C program, if you know what hazards to avoid, it isn't much harder to write it (without ifdefs) so that it's also a correct C++ program.

Although many may prefer C to C++, no one would propose C as a successor to C++. Nevertheless, it's valuable to both communities to maintain this almost-compatible-subset property between the languages. Likewise, it would make no sense to propose Caja as a successor to ES3.

So, depending on what you mean, I might argue with your phrase "incompatible subset". We are seeking to create, as close as we possibly can, a compatible subset. If you see a way in which we could be more compatible while still meeting our other goals, please let us know. Thanks.

Also, could you explain the phrase "profiled standards"? Thanks.

 

Anyway, it's early days for Caja and other such systems. If TG1 continues to function, it should definitely harvest good ideas from it, and stand on shoulders, not toes.

Thank you. I will read the ES4 proposal carefully and let you know what shoulder and toe issues I find.

 

We've pressed Doug Crockford on this point and heard nothing in the way of concrete proposals, save for a small one I championed at the last face-to-face meeting (a better-isolated String.prototype.evaluate() taking a scope object). But that went nowhere for lack of effort -- I half expect it to turn up in "Microsoft's vision for ECMAScript", which would make a fork in the standard. I'll still try to rescue it for ES4, but it's just a small isolation device, good to have, but not nearly enough for "Security" with a capital S.

I would like to hear more about this. A safe eval primitive that provides good isolation could actually be a very powerful lever for expressive security. Chapter 10 of < http://erights.org/talks/thesis/> tries to explain some of the relevant issues. Unfortunately, this is the most confusing and badly written chapter of that document, and badly needs a rewrite. If you do wade into it and find it confusing, please do not hesitate to ask me to clarify.

--
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Chris Pine-2]

Maciej Stachowiak wrote:

>
> On Oct 30, 2007, at 1:01 PM, Chris Pine wrote:
>
>> Maciej Stachowiak wrote:
>>
>>> Can anyone address feasibility of a small full implementation
>>> (source  code all the way to execution)?
>>
>> If we didn't think it was feasible, we wouldn't be here.  :)  While we
>> don't have a full implementation yet (no one does), progress is
>> looking good.  Our latest engine, just out in Opera 9.5 beta, is both
>> smaller and considerably faster than our previous engine (which we've
>> shipped on many small devices).  It runs on devices smaller than an
>> iPhone, no problem.  (How much ram does an iPhone have?  I don't see
>> that on Apple's site.)
>
> Does your latest shipping engine implement parts of ES4? If so, how much?

Not much.  Our first focus was to reduce and speed up what we have, to
make room for the new features.  And we are still not done with that; we
can make this puppy smaller, yet.


> 2) Size of the ES4 standard library by count of classes, methods and
> properties.

This really isn't changing much.

Chris
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

> -----Original Message-----
> From: es4-discuss-bounces@... On Behalf Of Maciej Stachowiak
> Sent: 30. oktober 2007 21:23
>
> By the way, I think the discussions about language size could
> benefit from some quantitative data. I think the following
> comparisons would be interesting:

...

> 2) Size of the ES4 standard library by count of classes,
> methods and properties.

Below is a breakdown of classes (C), interfaces (I), types (T),
functions (F), methods (M), properties (P), variables/constants (V); *
means new in ES4, + means it replaces something else in ES3 (typically a
"primitive value").  "s" means "static", "p" means prototype.  Based on
current understanding; expect some minor adjustment over time.

Do not count lines uncritically.  Where ES3 had prototype methods, ES4
has intrinsic methods in addition and sometimes generic static methods
as well (Array, String, Function), but in almost all cases, only one of
the set has a nontrivial body and the others delegate to it.
Furthermore, many "String" methods delegate to "string" methods, and
there are shared prototypes (String and String; byte, int, uint, double,
decimal, and Number; boolean and Boolean).  As a consequence, the
footprint for the library is probably substantially smaller than it
would appear at first glance.  (Note also that [[Construct]] and
[[Call]] have new names but are not new.)

--lars


* V __ECMASCRIPT_OBJECT__                        [version number]
* V __ES4__                                      [reserved namespace
constant]
* V __ES4__::intrinsic                           [reserved namespace
constant]
* V __ES4__::meta                                [reserved namespace
constant]
* V __ES4__::reflect                             [reserved namespace
constant]

  C Object
  Ms  Object
  Ms  meta::invoke
  Vs  length
  Vs  prototype
  Mp  toString
  Mp  toLocaleString
* Mp  toJSONString
  Mp  hasOwnProperty
  Mp  isPrototypeOf
  Mp  propertyIsEnumerable
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::hasOwnProperty
* M   intrinsic::isPrototypeOf
* M   intrinsic::propertyIsEnumerable

  C Function
  Ms  Function
  Ms  meta::invoke
  Vs  length
  Vs  prototype
* Ms  apply
* Ms  call
  M   meta::invoke
  V   length
  V   prototype
  Mp  toString
  Mp  apply
  Mp  call
* M   intrinsic::toString
* M   intrinsic::apply
* M   intrinsic::call

* C __ES4__::GenericFunction                     [proposed, not fully
spec'd]

  C Array
  Ms  Array
  Ms  meta::invoke
  Vs  length
* Ms  concat
* Ms  every
* Ms  filter
* Ms  forEach
* Ms  indexOf
* Ms  join
* Ms  lastIndexOf
* Ms  map
* Ms  pop
* Ms  push
* Ms  reverse
* Ms  shift
* Ms  slice
* Ms  some
* Ms  sort
* Ms  splice
* Ms  unshift
  Mp  concat
  Mp  every
  Mp  filter
  Mp  forEach
  Mp  indexOf
  Mp  join
  Mp  lastIndexOf
  Mp  map
  Mp  pop
  Mp  push
  Mp  reverse
  Mp  shift
  Mp  slice
  Mp  some
  Mp  sort
  Mp  splice
  Mp  unshift
  M   get length
  M   set length
* M   intrinsic::concat
* M   intrinsic::every
* M   intrinsic::filter
* M   intrinsic::forEach
* M   intrinsic::indexOf
* M   intrinsic::join
* M   intrinsic::lastIndexOf
* M   intrinsic::map
* M   intrinsic::pop
* M   intrinsic::push
* M   intrinsic::reverse
* M   intrinsic::shift
* M   intrinsic::slice
* M   intrinsic::some
* M   intrinsic::sort
* M   intrinsic::splice
* M   intrinsic::unshift

  C String
  Ms  String
  Ms  meta::invoke
  Vs  length
  Ms  fromCharCode
* Ms  charAt
* Ms  charCodeAt
* Ms  concat
* Ms  indexOf
* Ms  lastIndexOf
* Ms  localeCompare
* Ms  match
* Ms  parseJSON
* Ms  replace
* Ms  search
* Ms  slice
* Ms  split
* Ms  substring
* Ms  toLowerCase
* Ms  toLocaleLowerCase
* Ms  toUpperCase
* Ms  toLocaleUpperCase
* Ms  trim
  Mp  charAt
  Mp  charCodeAt
  Mp  concat
  Mp  indexOf
  Mp  lastIndexOf
  Mp  localeCompare
  Mp  match
  Mp  parseJSON
  Mp  replace
  Mp  search
  Mp  slice
  Mp  split
  Mp  substring
  Mp  toLowerCase
  Mp  toLocaleLowerCase
  Mp  toUpperCase
  Mp  toLocaleUpperCase
  Mp  trim
  M   get length
* M   get
* M   intrinsic::charAt
* M   intrinsic::charCodeAt
* M   intrinsic::concat
* M   intrinsic::indexOf
* M   intrinsic::lastIndexOf
* M   intrinsic::localeCompare
* M   intrinsic::match
* M   intrinsic::parseJSON
* M   intrinsic::replace
* M   intrinsic::search
* M   intrinsic::slice
* M   intrinsic::split
* M   intrinsic::substring
* M   intrinsic::toLowerCase
* M   intrinsic::toLocaleLowerCase
* M   intrinsic::toUpperCase
* M   intrinsic::toLocaleUpperCase
* M   intrinsic::trim

+ C __ES4__::string
* Ms  string
* Ms  meta::invoke
* Vs  length
* Ms  fromCharCode
* Ms  charAt
* Ms  charCodeAt
* Ms  concat
* Ms  indexOf
* Ms  lastIndexOf
* Ms  localeCompare
* Ms  match
* Ms  parseJSON
* Ms  replace
* Ms  search
* Ms  slice
* Ms  split
* Ms  substring
* Ms  toLowerCase
* Ms  toLocaleLowerCase
* Ms  toUpperCase
* Ms  toLocaleUpperCase
* Ms  trim
* M   get length
* M   get
* M   intrinsic::charAt
* M   intrinsic::charCodeAt
* M   intrinsic::concat
* M   intrinsic::indexOf
* M   intrinsic::lastIndexOf
* M   intrinsic::localeCompare
* M   intrinsic::match
* M   intrinsic::parseJSON
* M   intrinsic::replace
* M   intrinsic::search
* M   intrinsic::slice
* M   intrinsic::split
* M   intrinsic::substring
* M   intrinsic::toLowerCase
* M   intrinsic::toLocaleLowerCase
* M   intrinsic::toUpperCase
* M   intrinsic::toLocaleUpperCase
* M   intrinsic::trim

  C Boolean
  Ms  Boolean
  Ms  meta::invoke
  Vs  length
  Mp  toString
* Mp  toJSONString
  Mp  valueOf
* M   intrinsic::toString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf

+ C __ES4__::boolean
* Ms  boolean
* Ms  meta::invoke
* Vs  length
* M   intrinsic::toString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf

  C Number
  Ms  Number
  Ms  meta::invoke
  Vs  length
  Vs  MAX_VALUE
  Vs  MIN_VALUE
  Vs  NaN
  Vs  NEGATIVE_INFINITY
  Vs  POSITIVE_INFINITY
  Mp  toString
  Mp  toLocaleString
* Mp  toJSONString
  Mp  valueOf
  Mp  toFixed
  Mp  toExponential
  Mp  toPrecision
  M   intrinsic::toString
  M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
  M   intrinsic::valueOf
  M   intrinsic::toFixed
  M   intrinsic::toExponential
  M   intrinsic::toPrecision

* C __ES4__::byte
  Ms  meta::invoke
  Vs  length
  Vs  MAX_VALUE
  Vs  MIN_VALUE

* C __ES4__::int
* Ms  int
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

* C __ES4__::uint
* Ms  uint
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

+ C __ES4__::double
* Ms  double
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* Vs  NaN
* Vs  NEGATIVE_INFINITY
* Vs  POSITIVE_INFINITY
* Vs  E
* Vs  LN10
* Vs  LN2
* Vs  LOG2E
* Vs  LOG10E
* Vs  PI
* Vs  SQRT1_2
* Vs  SQRT2
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

* C __ES4__::decimal
* Ms  int
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* Vs  NaN
* Vs  NEGATIVE_INFINITY
* Vs  POSITIVE_INFINITY
* Vs  E
* Vs  LN10
* Vs  LN2
* Vs  LOG2E
* Vs  LOG10E
* Vs  PI
* Vs  SQRT1_2
* Vs  SQRT2
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

  C Date
  Ms  Date
  Ms  meta::invoke
* Ms  intrinsic::parse
* Ms  intrinsic::UTC
  Ms  now
  Vs  parse
  Vs  UTC
  Vs  length
  Mp  toString
  Mp  toDateString
  Mp  toTimeString
  Mp  toLocaleString
  Mp  toLocaleDateString
  Mp  toLocaleTimeString
  Mp  toUTCString
* Mp  toISOString
* Mp  toJSONString
  Mp  valueOf
  Mp  nanoAge
  Mp  getTime
  Mp  getFullYear
  Mp  getUTCFullYear
  Mp  getMonth
  Mp  getUTCMonth
  Mp  getDate
  Mp  getUTCDate
  Mp  getDay
  Mp  getUTCDay
  Mp  getHours
  Mp  getUTCHours
  Mp  getMinutes
  Mp  getUTCMinutes
  Mp  getSeconds
  Mp  getUTCSeconds
  Mp  getMilliseconds
  Mp  getUTCMilliseconds
  Mp  getTimezoneOffset
  Mp  setTime
  Mp  setMilliseconds
  Mp  setUTCMilliseconds
  Mp  setSeconds
  Mp  setUTCSeconds
  Mp  setMinutes
  Mp  setUTCMinutes
  Mp  setHours
  Mp  setUTCHours
  Mp  setDate
  Mp  setUTCDate
  Mp  setMonth
  Mp  setUTCMonth
  Mp  setFullYear
  Mp  setUTCFullYear
* M   intrinsic::nanoAge
* M   intrinsic::toString
* M   intrinsic::toDateString
* M   intrinsic::toTimeString
* M   intrinsic::toLocaleString
* M   intrinsic::toLocaleDateString
* M   intrinsic::toLocaleTimeString
* M   intrinsic::toUTCString
* M   intrinsic::toISOString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::getTime
* M   intrinsic::getFullYear
* M   intrinsic::getUTCFullYear
* M   intrinsic::getMonth
* M   intrinsic::getUTCMonth
* M   intrinsic::getDate
* M   intrinsic::getUTCDate
* M   intrinsic::getDay
* M   intrinsic::getUTCDay
* M   intrinsic::getHours
* M   intrinsic::getUTCHours
* M   intrinsic::getMinutes
* M   intrinsic::getUTCMinutes
* M   intrinsic::getSeconds
* M   intrinsic::getUTCSeconds
* M   intrinsic::getMilliseconds
* M   intrinsic::getUTCMilliseconds
* M   intrinsic::getTimezoneOffset
* M   intrinsic::setTime
* M   intrinsic::setMilliseconds
* M   intrinsic::setUTCMilliseconds
* M   intrinsic::setSeconds
* M   intrinsic::setUTCSeconds
* M   intrinsic::setMinutes
* M   intrinsic::setUTCMinutes
* M   intrinsic::setHours
* M   intrinsic::setUTCHours
* M   intrinsic::setDate
* M   intrinsic::setUTCDate
* M   intrinsic::setMonth
* M   intrinsic::setUTCMonth
* M   intrinsic::setFullYear
* M   intrinsic::setUTCFullYear
* M   get time
* M   get year
* M   get month
* M   get UTCMonth
* M   get date
* M   get UTCDate
* M   get day
* M   get UTCDay
* M   get hours
* M   get UTCHours
* M   get minutes
* M   get UTCMinutes
* M   get seconds
* M   get UTCSeconds
* M   get milliseconds
* M   get UTCMilliseconds
* M   set time
* M   set year
* M   set fullYear
* M   set UTCFullYear
* M   set month
* M   set UTCMonth
* M   set date
* M   set UTCDate
* M   set hours
* M   set UTCHours
* M   set minutes
* M   set UTCMinutes
* M   set seconds
* M   set UTCSeconds
* M   set milliseconds
* M   set UTCMilliseconds

  C RegExp
  Ms  RegExp
  Ms  meta::invoke
  Vs  length
  Mp  toString
  Mp  exec
  Mp  test
* M   meta::invoke
* M   intrinsic::toString
* M   intrinsic::exec
* M   intrinsic::test
  V   source
  V   global
  V   ignoreCase
  V   multiline
* V   extended
* V   sticky
  V   lastIndex

  C Error
  Ms  Error
  Ms  meta::invoke
  Vs  length
  V   name
  V   message

  C EvalError extends Error
  Ms  EvalError
  Ms  meta::invoke
  Vs  length

  C RangeError extends Error
  Ms  RangeError
  Ms  meta::invoke
  Vs  length

  C ReferenceError extends Error
  Ms  ReferenceError
  Ms  meta::invoke
  Vs  length

  C SyntaxError extends Error
  Ms  SyntaxError
  Ms  meta::invoke
  Vs  length

  C TypeError extends Error
  Ms  TypeError
  Ms  meta::invoke
  Vs  length

  C URIError extends Error
  Ms  URIError
  Ms  meta::invoke
  Vs  length

* C __ES4__::EncodingError extends Error         [for JSON]
* Ms  EncodingError
* Ms  meta::invoke
* Vs  length

* C __ES4__::Name
* Ms  Name
* Ms  meta::invoke
* Mp  toString
* Mp  valueOf
* M   intrinsic::toString
* M   intrinsic::ValueOf
* V   qualifier
* V   identifier

* C __ES4__::Namespace
* Mp  toString
* M   intrinsic::toString

* C __ES4__::NamespaceSet                        [TBD -- small class]

* C __ES4__::NamespaceSetList                    [TBD -- small class]

* C __ES4__::Map.<K,V>
* Ms  Map
* M   intrinsic::size
* M   intrinsic::get
* M   intrinsic::put
* M   intrinsic::has
* M   intrinsic::remove
* Mp  size
* Mp  get
* Mp  put
* M   phas
* Mp  remove
* M   iterator::get
* M   iterator::getKeys
* M   iterator::getValues
* M   iterator::getItems

* C __ES4__::Vector.<T>
* Ms  Vector
* Ms  meta::invoke
* Vs  length
* Mp  concat
* Mp  every
* Mp  filter
* Mp  forEach
* Mp  indexOf
* Mp  join
* Mp  lastIndexOf
* Mp  map
* Mp  pop
* Mp  push
* Mp  reverse
* Mp  shift
* Mp  slice
* Mp  some
* Mp  sort
* Mp  splice
* Mp  unshift
* M   get length
* M   set length
* V   fixed
* M   meta::get
* M   meta::set
* M   intrinsic::concat
* M   intrinsic::every
* M   intrinsic::filter
* M   intrinsic::forEach
* M   intrinsic::indexOf
* M   intrinsic::join
* M   intrinsic::lastIndexOf
* M   intrinsic::map
* M   intrinsic::pop
* M   intrinsic::push
* M   intrinsic::reverse
* M   intrinsic::shift
* M   intrinsic::slice
* M   intrinsic::some
* M   intrinsic::sort
* M   intrinsic::splice
* M   intrinsic::unshift
* M   iterator::get
* M   iterator::getKeys
* M   iterator::getValues
* M   iterator::getItems

* C intrinsic::ControlInspector.<T>              [may end up in
reflect::]
* Ms  ControlInspector
* M   annotate
* M   getCurrentAnnotation
* M   getAnnotation

* T __ES4__::AnyNumber

* T __ES4__::AnyString

* T __ES4__::AnyBoolean

* T __ES4__::EnumerableId

* I reflect::Type
* M   canConvertTo
* M   isSubtypeOf

* I reflect::NominalType
* M   name
* M   superTypes
* M   [a few more here, TBD]

* I reflect::InterfaceType
* M   implementedBy

* I reflect::ClassType
* M   construct

* I reflect::AnyType

* I reflect::NullType

* I reflect::UndefinedType

* I reflect::UnionType
* M   fields
* M   members

* I reflect::RecordType
* M   construct

* I reflect::FunctionType
* M   boundThid
* M   argTypes
* M   defaultValues
* M   hasRestType
* M   returnType

* I reflect::ArrayType
* M   fields
* M   members

* I reflect::ParameterizedType

* I reflect::Field
* M   name
* M   type

* I reflect::FieldValue
* M   name
* M   value

  F eval
  F parseInt
  F parseFloat
  F isNaN
  F isFinite
  F decodeURI
  F decodeURIComponent
  F encodeURI
  F encodeURIComponent

  V Math
  V   E
  V   LN10
  V   LN2
  V   LOG2E
  V   LOG10E
  V   PI
  V   SQRT1_2
  V   SQRT2
  M   acos
  M   atan
  M   atan2
  M   ceil
  M   cos
  M   exp
  M   floor
  M   log
  M   max
  M   min
  M   pow
  M   random
  M   round
  M   sin
  M   sqrt
  M   tan
* M   intrinsic::acos
* M   intrinsic::atan
* M   intrinsic::atan2
* M   intrinsic::ceil
* M   intrinsic::cos
* M   intrinsic::exp
* M   intrinsic::floor
* M   intrinsic::log
* M   intrinsic::max
* M   intrinsic::min
* M   intrinsic::pow
* M   intrinsic::random
* M   intrinsic::round
* M   intrinsic::sin
* M   intrinsic::sqrt
* M   intrinsic::tan

  V NaN
  V Infinity
  V undefined
* F intrinsic::eval
* F intrinsic::parseInt
* F intrinsic::parseFloat
* F intrinsic::isNaN
* F intrinsic::isFinite
* F intrinsic::decodeURI
* F intrinsic::decodeURIComponent
* F intrinsic::encodeURI
* F intrinsic::encodeURIComponent
* V intrinsic::global
* F reflect::typeOf

>
> I am willing to run the number on these if someone can help
> me find the grammar and some sort of standard library index
> in the spec.
>
> Regards,
> Maciej
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss
>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Oct 30, 2007, at 1:23 PM, Maciej Stachowiak wrote:

> By the way, I think the discussions about language size could benefit
> from some quantitative data. I think the following comparisons would
> be interesting:
>
> 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count
> of productions).

Excluding the lexical grammar, the E4X syntax rules (which won't be a  
normative requirement) and regular expression syntax, I count:

ECMA-262 3rd Edition: 74 grammar productions
ECMAScript 4th edition draft: 197 grammar productions

That's a more than 2x increase in surface syntax (2.66x to be more  
exact). While not completely unreasonable given all the new features,  
it seems a little high. Before embarking on this exercise I thought  
that 2x would be a reasonable level of core syntax increase. Part of  
this may be simply due to better factoring of the grammar, and due to  
capturing features like auto semicolon insertion, how if is  
disambiguated, noin contexts, etc in more detail.

A lot of the genuinely new stuff just seems to be fallout from the  
type system.

I notice some seemingly duplicate features that will perhaps become  
more clear on closer reading of the spec. For instance I see all three  
of namespace, package and unit productions in the grammar. With my  
limited imagination it's hard to think of how those could be three  
interestingly different features.

> 2) Size of the ES4 standard library by count of classes, methods and
> properties.

I'll try to look at this soon, too. I think 4-5x would be about the  
size that would not raise any red flags for me, given how impoverished  
the ES3 standard library is.

Does anyone else have other ideas for objective metrics of language  
size?

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

> -----Original Message-----
> From: es4-discuss-bounces@...
> [mailto:es4-discuss-bounces@...] On Behalf Of Maciej
> Stachowiak
> Sent: 31. oktober 2007 11:47
> To: Maciej Stachowiak
> Cc: es4-discuss; Steven Johnson; Chris Pine
> Subject: Re: Language Size (was Re: [TLUG]: ECMAScript
> ("Javascript") Version4 - FALSE ALARM)
>
>
> Does anyone else have other ideas for objective metrics of
> language size?

Complexity of the implementation, certainly.  Complexity of the
semantics, maybe.

I joined TG1 in early 2006 as a representative of Opera (the position
Chris Pine occupies now).  My main concern was then to make sure the new
language could be handled by an implementation that would just read
source code off the wire and compile it in an on-line fashion,
generating code as it went along, without building trees for anything
more complex than expressions and without maintaining databases of
compiler-only data.  (I know for a fact this is possible for ES3, and it
would be helpful to embedded implementations if it was also possible for
ES4.)  The language should be implementable by a system that could, as
Graydon wrote the other day, evaluate everything lazily and not worry
about a thing until it couldn't put them off any longer, just like the
case is for ES3.

(A fallout of that (my victory or my fault, depending on how you see it)
is that ES4 does not require things like definite assignment analysis,
which would have required more elaborate data structures than a compiler
on an embedded system would be happy with.  Instead we have a syntactic
workaround (the "settings" section of the constructor) and other rules
to handle non-nullability.  Kludgy?  Depends on your point of view.  My
view is that embedded is a prime target for the language, and we adapt
accordingly.  Until most phones have fast CPUs and a lot of RAM,
embedded is hard.)

I still think that ES4 can be compiled that way, classes and packages
and parameterized types and all.  And I do think that says something
about the relatively low complexity of the language and how fit it is
for difficult environments.

(In fairness, we don't know yet how well a commercial implementation can
do on-line compilation under the pressure of performance requirements
both for the compiler and for the compiled code, but I have confidence,
based on no little experience from ES3, that it will be fine.)

--lars
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[wycats]

Some parts of this message have been removed. Learn more about Nabble's security policy.

---------- Forwarded message ----------
From: Yehuda Katz <wycats@...>
Date: Oct 31, 2007 3:58 AM
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version 4 -FALSE ALARM)
To: Lars Hansen <lhansen@...>

A massive chunk of these are the duplicate methods in the intrinsic namespace. If you remove those, you actually have very few new classes or methods (see below). Another big chunk is getters and setters that represent old ES3 methods pre-getters and setters.

 

Specifically, removing the duplicate intrinsic methods (but not removing replacing getters/setters, etc.), there are 256 new items on this list, vs. 276 old methods. Hardly "bloated".

 

* V __ECMASCRIPT_OBJECT__                        [version number]

* V __ES4__                                      [reserved namespace constant]

* V __ES4__::intrinsic                           [reserved namespace constant]

* V __ES4__::meta                                [reserved namespace constant]

* V __ES4__::reflect                             [reserved namespace constant]

 

 C Object

 Ms  Object

 Ms  meta::invoke

 Vs  length

 Vs  prototype

 Mp  toString

 Mp  toLocaleString

* Mp  toJSONString

 Mp  hasOwnProperty

 Mp  isPrototypeOf

 Mp  propertyIsEnumerable

 

 C Function

 Ms  Function

 Ms  meta::invoke

 Vs  length

 Vs  prototype

* Ms  apply

* Ms  call

 M   meta::invoke

 V   length

 V   prototype

 Mp  toString

 Mp  apply

 Mp  call

 

* C __ES4__::GenericFunction                     [proposed, not fully spec'd]

 

 C Array

 Ms  Array

 Ms  meta::invoke

 Vs  length

* Ms  concat

* Ms  every

* Ms  filter

* Ms  forEach

* Ms  indexOf

* Ms  join

* Ms  lastIndexOf

* Ms  map

* Ms  pop

* Ms  push

* Ms  reverse

* Ms  shift

* Ms  slice

* Ms  some

* Ms  sort

* Ms  splice

* Ms  unshift

 Mp  concat

 Mp  every

 Mp  filter

 Mp  forEach

 Mp  indexOf

 Mp  join

 Mp  lastIndexOf

 Mp  map

 Mp  pop

 Mp  push

 Mp  reverse

 Mp  shift

 Mp  slice

 Mp  some

 Mp  sort

 Mp  splice

 Mp  unshift

 M   get length

 M   set length

 C String

 Ms  String

 Ms  meta::invoke

 Vs  length

 Ms  fromCharCode

* Ms  charAt

* Ms  charCodeAt

* Ms  concat

* Ms  indexOf

* Ms  lastIndexOf

* Ms  localeCompare

* Ms  match

* Ms  parseJSON

* Ms  replace

* Ms  search

* Ms  slice

* Ms  split

* Ms  substring

* Ms  toLowerCase

* Ms  toLocaleLowerCase

* Ms  toUpperCase

* Ms  toLocaleUpperCase

* Ms  trim

 Mp  charAt

 Mp  charCodeAt

 Mp  concat

 Mp  indexOf

 Mp  lastIndexOf

 Mp  localeCompare

 Mp  match

 Mp  parseJSON

 Mp  replace

 Mp  search

 Mp  slice

 Mp  split

 Mp  substring

 Mp  toLowerCase

 Mp  toLocaleLowerCase

 Mp  toUpperCase

 Mp  toLocaleUpperCase

 Mp  trim

 M   get length

 

+ C __ES4__::string

* Ms  string

* Ms  meta::invoke

* Vs  length

* Ms  fromCharCode

* Ms  charAt

* Ms  charCodeAt

* Ms  concat

* Ms  indexOf

* Ms  lastIndexOf

* Ms  localeCompare

* Ms  match

* Ms  parseJSON

* Ms  replace

* Ms  search

* Ms  slice

* Ms  split

* Ms  substring

* Ms  toLowerCase

* Ms  toLocaleLowerCase

* Ms  toUpperCase

* Ms  toLocaleUpperCase

* Ms  trim

* M   get length

* M   get

 

 C Boolean

 Ms  Boolean

 Ms  meta::invoke

 Vs  length

 Mp  toString

* Mp  toJSONString

 Mp  valueOf

 

+ C __ES4__::boolean

* Ms  boolean

* Ms  meta::invoke

* Vs  length

 

 C Number

 Ms  Number

 Ms  meta::invoke

 Vs  length

 Vs  MAX_VALUE

 Vs  MIN_VALUE

 Vs  NaN

 Vs  NEGATIVE_INFINITY

 Vs  POSITIVE_INFINITY

 Mp  toString

 Mp  toLocaleString

* Mp  toJSONString

 Mp  valueOf

 Mp  toFixed

 Mp  toExponential

 Mp  toPrecision

 

* C __ES4__::byte

 Ms  meta::invoke

 Vs  length

 Vs  MAX_VALUE

 Vs  MIN_VALUE

 

* C __ES4__::int

* Ms  int

* Ms  meta::invoke

* Vs  length

* Vs  MAX_VALUE

* Vs  MIN_VALUE

 

* C __ES4__::uint

* Ms  uint

* Ms  meta::invoke

* Vs  length

* Vs  MAX_VALUE

* Vs  MIN_VALUE

 

+ C __ES4__::double

* Ms  double

* Ms  meta::invoke

* Vs  length

* Vs  MAX_VALUE

* Vs  MIN_VALUE

* Vs  NaN

* Vs  NEGATIVE_INFINITY

* Vs  POSITIVE_INFINITY

* Vs  E

* Vs  LN10

* Vs  LN2

* Vs  LOG2E

* Vs  LOG10E

* Vs  PI

* Vs  SQRT1_2

* Vs  SQRT2

 

* C __ES4__::decimal

* Ms  int

* Ms  meta::invoke

* Vs  length

* Vs  MAX_VALUE

* Vs  MIN_VALUE

* Vs  NaN

* Vs  NEGATIVE_INFINITY

* Vs  POSITIVE_INFINITY

* Vs  E

* Vs  LN10

* Vs  LN2

* Vs  LOG2E

* Vs  LOG10E

* Vs  PI

* Vs  SQRT1_2

* Vs  SQRT2

 

 C Date

 Ms  Date

 Ms  meta::invoke

 Ms  now

 Vs  parse

 Vs  UTC

 Vs  length

 Mp  toString

 Mp  toDateString

 Mp  toTimeString

 Mp  toLocaleString

 Mp  toLocaleDateString

 Mp  toLocaleTimeString

 Mp  toUTCString

* Mp  toISOString

* Mp  toJSONString

 Mp  valueOf

 Mp  nanoAge

 Mp  getTime

 Mp  getFullYear

 Mp  getUTCFullYear

 Mp  getMonth

 Mp  getUTCMonth

 Mp  getDate

 Mp  getUTCDate

 Mp  getDay

 Mp  getUTCDay

 Mp  getHours

 Mp  getUTCHours

 Mp  getMinutes

 Mp  getUTCMinutes

 Mp  getSeconds

 Mp  getUTCSeconds

 Mp  getMilliseconds

 Mp  getUTCMilliseconds

 Mp  getTimezoneOffset

 Mp  setTime

 Mp  setMilliseconds

 Mp  setUTCMilliseconds

 Mp  setSeconds

 Mp  setUTCSeconds

 Mp  setMinutes

 Mp  setUTCMinutes

 Mp  setHours

 Mp  setUTCHours

 Mp  setDate

 Mp  setUTCDate

 Mp  setMonth

 Mp  setUTCMonth

 Mp  setFullYear

 Mp  setUTCFullYear

* M   get time

* M   get year

* M   get month

* M   get UTCMonth

* M   get date

* M   get UTCDate

* M   get day

* M   get UTCDay

* M   get hours

* M   get UTCHours

* M   get minutes

* M   get UTCMinutes

* M   get seconds

* M   get UTCSeconds

* M   get milliseconds

* M   get UTCMilliseconds

* M   set time

* M   set year

* M   set fullYear

* M   set UTCFullYear

* M   set month

* M   set UTCMonth

* M   set date

* M   set UTCDate

* M   set hours

* M   set UTCHours

* M   set minutes

* M   set UTCMinutes

* M   set seconds

* M   set UTCSeconds

* M   set milliseconds

* M   set UTCMilliseconds

 

 C RegExp

 Ms  RegExp

 Ms  meta::invoke

 Vs  length

 Mp  toString

 Mp  exec

 Mp  test

* M   meta::invoke

 V   source

 V   global

 V   ignoreCase

 V   multiline

* V   extended

* V   sticky

 V   lastIndex

 

 C Error

 Ms  Error

 Ms  meta::invoke

 Vs  length

 V   name

 V   message

 C EvalError extends Error

 Ms  EvalError

 Ms  meta::invoke

 Vs  length

 

 C RangeError extends Error

 Ms  RangeError

 Ms  meta::invoke

 Vs  length

 

 C ReferenceError extends Error

 Ms  ReferenceError

 Ms  meta::invoke

 Vs  length

 

 C SyntaxError extends Error

 Ms  SyntaxError

 Ms  meta::invoke

 Vs  length

 

 C TypeError extends Error

 Ms  TypeError

 Ms  meta::invoke

 Vs  length

 

 C URIError extends Error

 Ms  URIError

 Ms  meta::invoke

 Vs  length

 

* C __ES4__::EncodingError extends Error         [for JSON]

* Ms  EncodingError

* Ms  meta::invoke

* Vs  length

 

* C __ES4__::Name

* Ms  Name

* Ms  meta::invoke

* Mp  toString

* Mp  valueOf

* V   qualifier

* V   identifier

 

* C __ES4__::Namespace

* Mp  toString

 

* C __ES4__::NamespaceSet                        [TBD -- small class]

 

* C __ES4__::NamespaceSetList                    [TBD -- small class]

 

* C __ES4__::Map.<K,V>

* Ms  Map

* Mp  size

* Mp  get

* Mp  put

* M   phas

* Mp  remove

* M   iterator::get

* M   iterator::getKeys

* M   iterator::getValues

* M   iterator::getItems

 

* C __ES4__::Vector.<T>

* Ms  Vector

* Ms  meta::invoke

* Vs  length

* Mp  concat

* Mp  every

* Mp  filter

* Mp  forEach

* Mp  indexOf

* Mp  join

* Mp  lastIndexOf

* Mp  map

* Mp  pop

* Mp  push

* Mp  reverse

* Mp  shift

* Mp  slice

* Mp  some

* Mp  sort

* Mp  splice

* Mp  unshift

* M   get length

* M   set length

* V   fixed

* M   meta::get

* M   meta::set

* M   iterator::getKeys

* M   iterator::getValues

* M   iterator::getItems

 

* C intrinsic::ControlInspector.<T>              [may end up in reflect::]

* Ms  ControlInspector

* M   annotate

* M   getCurrentAnnotation

* M   getAnnotation

 

* T __ES4__::AnyNumber

* T __ES4__::AnyString

 

* T __ES4__::AnyBoolean

 

* T __ES4__::EnumerableId

* I reflect::Type

* M   canConvertTo

* M   isSubtypeOf

 

* I reflect::NominalType

* M   name

* M   superTypes

* M   [a few more here, TBD]

 

* I reflect::InterfaceType

* M   implementedBy

 

* I reflect::ClassType

* M   construct

 

* I reflect::AnyType

 

* I reflect::NullType

* I reflect::UndefinedType

 

* I reflect::UnionType

* M   fields

* M   members

 

* I reflect::RecordType

* M   construct

 

* I reflect::FunctionType

* M   boundThid

* M   argTypes

* M   defaultValues

* M   hasRestType

* M   returnType

 

* I reflect::ArrayType

* M   fields

* M   members

 

* I reflect::ParameterizedType

 

* I reflect::Field

* M   name

* M   type

 

* I reflect::FieldValue

* M   name

* M   value

 

 F eval

 F parseInt

 F parseFloat

 F isNaN

 F isFinite

 F decodeURI

 F decodeURIComponent

 F encodeURI

 F encodeURIComponent

 

 V Math

 V   E

 V   LN10

 V   LN2

 V   LOG2E

 V   LOG10E

 V   PI

 V   SQRT1_2

 V   SQRT2

 M   acos

 M   atan

 M   atan2

 M   ceil

 M   cos

 M   exp

 M   floor

 M   log

 M   max

 M   min

 M   pow

 M   random

 M   round

 M   sin

 M   sqrt

 M   tan

 V NaN

 V Infinity

 V undefined

* F reflect::typeOf

 

On 10/31/07, Lars Hansen <lhansen@...> wrote:

> -----Original Message-----
> From: es4-discuss-bounces@... On Behalf Of Maciej Stachowiak
> Sent: 30. oktober 2007 21:23
>
> By the way, I think the discussions about language size could
> benefit from some quantitative data. I think the following
> comparisons would be interesting:

...

> 2) Size of the ES4 standard library by count of classes,
> methods and properties.

Below is a breakdown of classes (C), interfaces (I), types (T),
functions (F), methods (M), properties (P), variables/constants (V); *
means new in ES4, + means it replaces something else in ES3 (typically a
"primitive value").  "s" means "static", "p" means prototype.  Based on
current understanding; expect some minor adjustment over time.

Do not count lines uncritically.  Where ES3 had prototype methods, ES4
has intrinsic methods in addition and sometimes generic static methods
as well (Array, String, Function), but in almost all cases, only one of
the set has a nontrivial body and the others delegate to it.
Furthermore, many "String" methods delegate to "string" methods, and
there are shared prototypes (String and String; byte, int, uint, double,
decimal, and Number; boolean and Boolean).  As a consequence, the
footprint for the library is probably substantially smaller than it
would appear at first glance.  (Note also that [[Construct]] and
[[Call]] have new names but are not new.)

--lars


* V __ECMASCRIPT_OBJECT__                        [version number]
* V __ES4__                                      [reserved namespace
constant]
* V __ES4__::intrinsic                           [reserved namespace
constant]
* V __ES4__::meta                                [reserved namespace
constant]
* V __ES4__::reflect                             [reserved namespace
constant]

  C Object
  Ms  Object
  Ms  meta::invoke
  Vs  length
  Vs  prototype
  Mp  toString
  Mp  toLocaleString
* Mp  toJSONString
  Mp  hasOwnProperty
  Mp  isPrototypeOf
  Mp  propertyIsEnumerable
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::hasOwnProperty
* M   intrinsic::isPrototypeOf
* M   intrinsic::propertyIsEnumerable

  C Function
  Ms  Function
  Ms  meta::invoke
  Vs  length
  Vs  prototype
* Ms  apply
* Ms  call
  M   meta::invoke
  V   length
  V   prototype
  Mp  toString
  Mp  apply
  Mp  call
* M   intrinsic::toString
* M   intrinsic::apply
* M   intrinsic::call

* C __ES4__::GenericFunction                     [proposed, not fully
spec'd]

  C Array
  Ms  Array
  Ms  meta::invoke
  Vs  length
* Ms  concat
* Ms  every
* Ms  filter
* Ms  forEach
* Ms  indexOf
* Ms  join
* Ms  lastIndexOf
* Ms  map
* Ms  pop
* Ms  push
* Ms  reverse
* Ms  shift
* Ms  slice
* Ms  some
* Ms  sort
* Ms  splice
* Ms  unshift
  Mp  concat
  Mp  every
  Mp  filter
  Mp  forEach
  Mp  indexOf
  Mp  join
  Mp  lastIndexOf
  Mp  map
  Mp  pop
  Mp  push
  Mp  reverse
  Mp  shift
  Mp  slice
  Mp  some
  Mp  sort
  Mp  splice
  Mp  unshift
  M   get length
  M   set length
* M   intrinsic::concat
* M   intrinsic::every
* M   intrinsic::filter
* M   intrinsic::forEach
* M   intrinsic::indexOf
* M   intrinsic::join
* M   intrinsic::lastIndexOf
* M   intrinsic::map
* M   intrinsic::pop
* M   intrinsic::push
* M   intrinsic::reverse
* M   intrinsic::shift
* M   intrinsic::slice
* M   intrinsic::some
* M   intrinsic::sort
* M   intrinsic::splice
* M   intrinsic::unshift

  C String
  Ms  String
  Ms  meta::invoke
  Vs  length
  Ms  fromCharCode
* Ms  charAt
* Ms  charCodeAt
* Ms  concat
* Ms  indexOf
* Ms  lastIndexOf
* Ms  localeCompare
* Ms  match
* Ms  parseJSON
* Ms  replace
* Ms  search
* Ms  slice
* Ms  split
* Ms  substring
* Ms  toLowerCase
* Ms  toLocaleLowerCase
* Ms  toUpperCase
* Ms  toLocaleUpperCase
* Ms  trim
  Mp  charAt
  Mp  charCodeAt
  Mp  concat
  Mp  indexOf
  Mp  lastIndexOf
  Mp  localeCompare
  Mp  match
  Mp  parseJSON
  Mp  replace
  Mp  search
  Mp  slice
  Mp  split
  Mp  substring
  Mp  toLowerCase
  Mp  toLocaleLowerCase
  Mp  toUpperCase
  Mp  toLocaleUpperCase
  Mp  trim
  M   get length
* M   get
* M   intrinsic::charAt
* M   intrinsic::charCodeAt
* M   intrinsic::concat
* M   intrinsic::indexOf
* M   intrinsic::lastIndexOf
* M   intrinsic::localeCompare
* M   intrinsic::match
* M   intrinsic::parseJSON
* M   intrinsic::replace
* M   intrinsic::search
* M   intrinsic::slice
* M   intrinsic::split
* M   intrinsic::substring
* M   intrinsic::toLowerCase
* M   intrinsic::toLocaleLowerCase
* M   intrinsic::toUpperCase
* M   intrinsic::toLocaleUpperCase
* M   intrinsic::trim

+ C __ES4__::string
* Ms  string
* Ms  meta::invoke
* Vs  length
* Ms  fromCharCode
* Ms  charAt
* Ms  charCodeAt
* Ms  concat
* Ms  indexOf
* Ms  lastIndexOf
* Ms  localeCompare
* Ms  match
* Ms  parseJSON
* Ms  replace
* Ms  search
* Ms  slice
* Ms  split
* Ms  substring
* Ms  toLowerCase
* Ms  toLocaleLowerCase
* Ms  toUpperCase
* Ms  toLocaleUpperCase
* Ms  trim
* M   get length
* M   get
* M   intrinsic::charAt
* M   intrinsic::charCodeAt
* M   intrinsic::concat
* M   intrinsic::indexOf
* M   intrinsic::lastIndexOf
* M   intrinsic::localeCompare
* M   intrinsic::match
* M   intrinsic::parseJSON
* M   intrinsic::replace
* M   intrinsic::search
* M   intrinsic::slice
* M   intrinsic::split
* M   intrinsic::substring
* M   intrinsic::toLowerCase
* M   intrinsic::toLocaleLowerCase
* M   intrinsic::toUpperCase
* M   intrinsic::toLocaleUpperCase
* M   intrinsic::trim

  C Boolean
  Ms  Boolean
  Ms  meta::invoke
  Vs  length
  Mp  toString
* Mp  toJSONString
  Mp  valueOf
* M   intrinsic::toString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf

+ C __ES4__::boolean
* Ms  boolean
* Ms  meta::invoke
* Vs  length
* M   intrinsic::toString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf

  C Number
  Ms  Number
  Ms  meta::invoke
  Vs  length
  Vs  MAX_VALUE
  Vs  MIN_VALUE
  Vs  NaN
  Vs  NEGATIVE_INFINITY
  Vs  POSITIVE_INFINITY
  Mp  toString
  Mp  toLocaleString
* Mp  toJSONString
  Mp  valueOf
  Mp  toFixed
  Mp  toExponential
  Mp  toPrecision
  M   intrinsic::toString
  M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
  M   intrinsic::valueOf
  M   intrinsic::toFixed
  M   intrinsic::toExponential
  M   intrinsic::toPrecision

* C __ES4__::byte
  Ms  meta::invoke
  Vs  length
  Vs  MAX_VALUE
  Vs  MIN_VALUE

* C __ES4__::int
* Ms  int
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

* C __ES4__::uint
* Ms  uint
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

+ C __ES4__::double
* Ms  double
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* Vs  NaN
* Vs  NEGATIVE_INFINITY
* Vs  POSITIVE_INFINITY
* Vs  E
* Vs  LN10
* Vs  LN2
* Vs  LOG2E
* Vs  LOG10E
* Vs  PI
* Vs  SQRT1_2
* Vs  SQRT2
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

* C __ES4__::decimal
* Ms  int
* Ms  meta::invoke
* Vs  length
* Vs  MAX_VALUE
* Vs  MIN_VALUE
* Vs  NaN
* Vs  NEGATIVE_INFINITY
* Vs  POSITIVE_INFINITY
* Vs  E
* Vs  LN10
* Vs  LN2
* Vs  LOG2E
* Vs  LOG10E
* Vs  PI
* Vs  SQRT1_2
* Vs  SQRT2
* M   intrinsic::toString
* M   intrinsic::toLocaleString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::toFixed
* M   intrinsic::toExponential
* M   intrinsic::toPrecision

  C Date
  Ms  Date
  Ms  meta::invoke
* Ms  intrinsic::parse
* Ms  intrinsic::UTC
  Ms  now
  Vs  parse
  Vs  UTC
  Vs  length
  Mp  toString
  Mp  toDateString
  Mp  toTimeString
  Mp  toLocaleString
  Mp  toLocaleDateString
  Mp  toLocaleTimeString
  Mp  toUTCString
* Mp  toISOString
* Mp  toJSONString
  Mp  valueOf
  Mp  nanoAge
  Mp  getTime
  Mp  getFullYear
  Mp  getUTCFullYear
  Mp  getMonth
  Mp  getUTCMonth
  Mp  getDate
  Mp  getUTCDate
  Mp  getDay
  Mp  getUTCDay
  Mp  getHours
  Mp  getUTCHours
  Mp  getMinutes
  Mp  getUTCMinutes
  Mp  getSeconds
  Mp  getUTCSeconds
  Mp  getMilliseconds
  Mp  getUTCMilliseconds
  Mp  getTimezoneOffset
  Mp  setTime
  Mp  setMilliseconds
  Mp  setUTCMilliseconds
  Mp  setSeconds
  Mp  setUTCSeconds
  Mp  setMinutes
  Mp  setUTCMinutes
  Mp  setHours
  Mp  setUTCHours
  Mp  setDate
  Mp  setUTCDate
  Mp  setMonth
  Mp  setUTCMonth
  Mp  setFullYear
  Mp  setUTCFullYear
* M   intrinsic::nanoAge
* M   intrinsic::toString
* M   intrinsic::toDateString
* M   intrinsic::toTimeString
* M   intrinsic::toLocaleString
* M   intrinsic::toLocaleDateString
* M   intrinsic::toLocaleTimeString
* M   intrinsic::toUTCString
* M   intrinsic::toISOString
* M   intrinsic::toJSONString
* M   intrinsic::valueOf
* M   intrinsic::getTime
* M   intrinsic::getFullYear
* M   intrinsic::getUTCFullYear
* M   intrinsic::getMonth
* M   intrinsic::getUTCMonth
* M   intrinsic::getDate
* M   intrinsic::getUTCDate
* M   intrinsic::getDay
* M   intrinsic::getUTCDay
* M   intrinsic::getHours
* M   intrinsic::getUTCHours
* M   intrinsic::getMinutes
* M   intrinsic::getUTCMinutes
* M   intrinsic::getSeconds
* M   intrinsic::getUTCSeconds
* M   intrinsic::getMilliseconds
* M   intrinsic::getUTCMilliseconds
* M   intrinsic::getTimezoneOffset
* M   intrinsic::setTime
* M   intrinsic::setMilliseconds
* M   intrinsic::setUTCMilliseconds
* M   intrinsic::setSeconds
* M   intrinsic::setUTCSeconds
* M   intrinsic::setMinutes
* M   intrinsic::setUTCMinutes
* M   intrinsic::setHours
* M   intrinsic::setUTCHours
* M   intrinsic::setDate
* M   intrinsic::setUTCDate
* M   intrinsic::setMonth
* M   intrinsic::setUTCMonth
* M   intrinsic::setFullYear
* M   intrinsic::setUTCFullYear
* M   get time
* M   get year
* M   get month
* M   get UTCMonth
* M   get date
* M   get UTCDate
* M   get day
* M   get UTCDay
* M   get hours
* M   get UTCHours
* M   get minutes
* M   get UTCMinutes
* M   get seconds
* M   get UTCSeconds
* M   get milliseconds
* M   get UTCMilliseconds
* M   set time
* M   set year
* M   set fullYear
* M   set UTCFullYear
* M   set month
* M   set UTCMonth
* M   set date
* M   set UTCDate
* M   set hours
* M   set UTCHours
* M   set minutes
* M   set UTCMinutes
* M   set seconds
* M   set UTCSeconds
* M   set milliseconds
* M   set UTCMilliseconds

  C RegExp
  Ms  RegExp
  Ms  meta::invoke
  Vs  length
  Mp  toString
  Mp  exec
  Mp  test
* M   meta::invoke
* M   intrinsic::toString
* M   intrinsic::exec
* M   intrinsic::test
  V   source
  V   global
  V   ignoreCase
  V   multiline
* V   extended
* V   sticky
  V   lastIndex

  C Error
  Ms  Error
  Ms  meta::invoke
  Vs  length
  V   name
  V   message

  C EvalError extends Error
  Ms  EvalError
  Ms  meta::invoke
  Vs  length

  C RangeError extends Error
  Ms  RangeError
  Ms  meta::invoke
  Vs  length

  C ReferenceError extends Error
  Ms  ReferenceError
  Ms  meta::invoke
  Vs  length

  C SyntaxError extends Error
  Ms  SyntaxError
  Ms  meta::invoke
  Vs  length

  C TypeError extends Error
  Ms  TypeError
  Ms  meta::invoke
  Vs  length

  C URIError extends Error
  Ms  URIError
  Ms  meta::invoke
  Vs  length

* C __ES4__::EncodingError extends Error         [for JSON]
* Ms  EncodingError
* Ms  meta::invoke
* Vs  length

* C __ES4__::Name
* Ms  Name
* Ms  meta::invoke
* Mp  toString
* Mp  valueOf
* M   intrinsic::toString
* M   intrinsic::ValueOf
* V   qualifier
* V   identifier

* C __ES4__::Namespace
* Mp  toString
* M   intrinsic::toString

* C __ES4__::NamespaceSet                        [TBD -- small class]

* C __ES4__::NamespaceSetList                    [TBD -- small class]

* C __ES4__::Map.<K,V>
* Ms  Map
* M   intrinsic::size
* M   intrinsic::get
* M   intrinsic::put
* M   intrinsic::has
* M   intrinsic::remove
* Mp  size
* Mp  get
* Mp  put
* M   phas
* Mp  remove
* M   iterator::get
* M   iterator::getKeys
* M   iterator::getValues
* M   iterator::getItems

* C __ES4__::Vector.<T>
* Ms  Vector
* Ms  meta::invoke
* Vs  length
* Mp  concat
* Mp  every
* Mp  filter
* Mp  forEach
* Mp  indexOf
* Mp  join
* Mp  lastIndexOf
* Mp  map
* Mp  pop
* Mp  push
* Mp  reverse
* Mp  shift
* Mp  slice
* Mp  some
* Mp  sort
* Mp  splice
* Mp  unshift
* M   get length
* M   set length
* V   fixed
* M   meta::get
* M   meta::set
* M   intrinsic::concat
* M   intrinsic::every
* M   intrinsic::filter
* M   intrinsic::forEach
* M   intrinsic::indexOf
* M   intrinsic::join
* M   intrinsic::lastIndexOf
* M   intrinsic::map
* M   intrinsic::pop
* M   intrinsic::push
* M   intrinsic::reverse
* M   intrinsic::shift
* M   intrinsic::slice
* M   intrinsic::some
* M   intrinsic::sort
* M   intrinsic::splice
* M   intrinsic::unshift
* M   iterator::get
* M   iterator::getKeys
* M   iterator::getValues
* M   iterator::getItems

* C intrinsic::ControlInspector.<T>              [may end up in
reflect::]
* Ms  ControlInspector
* M   annotate
* M   getCurrentAnnotation
* M   getAnnotation

* T __ES4__::AnyNumber

* T __ES4__::AnyString

* T __ES4__::AnyBoolean

* T __ES4__::EnumerableId

* I reflect::Type
* M   canConvertTo
* M   isSubtypeOf

* I reflect::NominalType
* M   name
* M   superTypes
* M   [a few more here, TBD]

* I reflect::InterfaceType
* M   implementedBy

* I reflect::ClassType
* M   construct

* I reflect::AnyType

* I reflect::NullType

* I reflect::UndefinedType

* I reflect::UnionType
* M   fields
* M   members

* I reflect::RecordType
* M   construct

* I reflect::FunctionType
* M   boundThid
* M   argTypes
* M   defaultValues
* M   hasRestType
* M   returnType

* I reflect::ArrayType
* M   fields
* M   members

* I reflect::ParameterizedType

* I reflect::Field
* M   name
* M   type

* I reflect::FieldValue
* M   name
* M   value

  F eval
  F parseInt
  F parseFloat
  F isNaN
  F isFinite
  F decodeURI
  F decodeURIComponent
  F encodeURI
  F encodeURIComponent

  V Math
  V   E
  V   LN10
  V   LN2
  V   LOG2E
  V   LOG10E
  V   PI
  V   SQRT1_2
  V   SQRT2
  M   acos
  M   atan
  M   atan2
  M   ceil
  M   cos
  M   exp
  M   floor
  M   log
  M   max
  M   min
  M   pow
  M   random
  M   round
  M   sin
  M   sqrt
  M   tan
* M   intrinsic::acos
* M   intrinsic::atan
* M   intrinsic::atan2
* M   intrinsic::ceil
* M   intrinsic::cos
* M   intrinsic::exp
* M   intrinsic::floor
* M   intrinsic::log
* M   intrinsic::max
* M   intrinsic::min
* M   intrinsic::pow
* M   intrinsic::random
* M   intrinsic::round
* M   intrinsic::sin
* M   intrinsic::sqrt
* M   intrinsic::tan

  V NaN
  V Infinity
  V undefined
* F intrinsic::eval
* F intrinsic::parseInt
* F intrinsic::parseFloat
* F intrinsic::isNaN
* F intrinsic::isFinite
* F intrinsic::decodeURI
* F intrinsic::decodeURIComponent
* F intrinsic::encodeURI
* F intrinsic::encodeURIComponent
* V intrinsic::global
* F reflect::typeOf

>
> I am willing to run the number on these if someone can help
> me find the grammar and some sort of standard library index
> in the spec.
>
> Regards,
> Maciej
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss
>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325

--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Harri Porten]

Hi!

On Wed, 31 Oct 2007, Maciej Stachowiak wrote:

> Does anyone else have other ideas for objective metrics of language
> size?

"Compilation time" - of course not that objective as heavily
implementation specific but still an indicator for the complexity of the
language :)

But seriously: from my own work on an ES4 interpreter (based on the
previous draft back then) I saw the biggest impact on the implementation
to be in the "compilation phase". This went hand in the hand with the
*advantages* of the type system, i.e. the possibility to apply
optimizations before execution.

In my personal book I therefore judge the complexity of a language also
based on the observation whether runtime implementations typically include
a compiler, i.e. offer an eval() function or not.

Harri.
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Oct 31, 2007, at 4:28 AM, Yehuda Katz wrote:

---------- Forwarded message ----------
From: Yehuda Katz <wycats@...>
Date: Oct 31, 2007 3:58 AM
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version 4 -FALSE ALARM)
To: Lars Hansen <lhansen@...>

A massive chunk of these are the duplicate methods in the intrinsic namespace. If you remove those, you actually have very few new classes or methods (see below). Another big chunk is getters and setters that represent old ES3 methods pre-getters and setters.

 

Specifically, removing the duplicate intrinsic methods (but not removing replacing getters/setters, etc.), there are 256 new items on this list, vs. 276 old methods. Hardly "bloated".

That doesn't exactly match my count, but close enough. For ES4 I removed all duplicate intrinsic:: names (not sure what these are for but I'll trust that they are not interestingly different), one of the two String classes, and meta::invoke. For ES3 I did not count [[Call]] internal properties or the like. I get:

ES3: 220

ES4: 437

Seems to be about the same ~2x increase that you report, though we used different methodologies to count. I would not count this as excessive growth, when it comes to the standard library.

Regards,

Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Oct 31, 2007, at 4:45 AM, Harri Porten wrote:

> Hi!
>
> On Wed, 31 Oct 2007, Maciej Stachowiak wrote:
>
>> Does anyone else have other ideas for objective metrics of language
>> size?
>
> "Compilation time" - of course not that objective as heavily
> implementation specific but still an indicator for the complexity of  
> the
> language :)
>
> But seriously: from my own work on an ES4 interpreter (based on the
> previous draft back then) I saw the biggest impact on the  
> implementation
> to be in the "compilation phase". This went hand in the hand with the
> *advantages* of the type system, i.e. the possibility to apply
> optimizations before execution.
>
> In my personal book I therefore judge the complexity of a language  
> also
> based on the observation whether runtime implementations typically  
> include
> a compiler, i.e. offer an eval() function or not.

Specifically comparing ES4 to ES3, I would hope for no significant  
increase in compilation time if one is willing to accept that there  
won't be much improvement in execution time. I am not sure if this is  
a reasonable expectation based on the spec, but it seems like many on  
the committee share roughly similar goals.

Cheers,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[wycats]

Incidentally, a fair but of what remains is Time getters/setters and the group of AnyNumber classes. If no one has done it by then, I'll do a chart of the largest groupings in the morning.

-- Yehuda

On 10/31/07, Maciej Stachowiak <mjs@...> wrote:

On Oct 31, 2007, at 4:28 AM, Yehuda Katz wrote:

---------- Forwarded message ----------
From: Yehuda Katz <wycats@...>
Date: Oct 31, 2007 3:58 AM
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version 4 -FALSE ALARM)
To: Lars Hansen <lhansen@...>

A massive chunk of these are the duplicate methods in the intrinsic namespace. If you remove those, you actually have very few new classes or methods (see below). Another big chunk is getters and setters that represent old ES3 methods pre-getters and setters.

 

Specifically, removing the duplicate intrinsic methods (but not removing replacing getters/setters, etc.), there are 256 new items on this list, vs. 276 old methods. Hardly "bloated".

 

That doesn't exactly match my count, but close enough. For ES4 I removed all duplicate intrinsic:: names (not sure what these are for but I'll trust that they are not interestingly different), one of the two String classes, and meta::invoke. For ES3 I did not count [[Call]] internal properties or the like. I get:

 

ES3: 220

ES4: 437

 

Seems to be about the same ~2x increase that you report, though we used different methodologies to count. I would not count this as excessive growth, when it comes to the standard library.

 

Regards,

Maciej

 

--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss