ToString for Numbers: reducing variation.

[David Jones]

After I wrote a blog article on this subject someone suggested I  
raise the issue here.

Currently, ECMA 262 3rd edition section 9.8.1, the ToString operator  
permits implementations to vary in how they convert certain numbers  
to strings.  For example the number 5e-324 could legally be converted  
as "3e-324", "4e-324", and so on up to "7e-324".

This would permit an implementation to evaluate the following  
expression as "undefined":

({5e-324:true})[5e-324]

I do not think any reasonable implementation would have a good reason  
for doing this.

It also permits the value of 'a' to vary between implementations in  
the following loop body:

for(a in {5e-324:true}) {...}

In order to ensure implementations all behave the same way I suggest  
the note at end of section 9.8.1 be moved to normative status.  As  
far as I can tell, the text is essentially the same between ECMA 262  
3rd edition and the Oslo draft published on 2008-07-04.

Cheers,
  drj

PS blog article at: http://drj11.wordpress.com/2008/07/11/javascript- 
using-numbers-as-table-keys-considered-harmful/
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ToString for Numbers: reducing variation.

[Waldemar Horwat]

David Jones wrote:
> After I wrote a blog article on this subject someone suggested I  
> raise the issue here.
> 
> Currently, ECMA 262 3rd edition section 9.8.1, the ToString operator  
> permits implementations to vary in how they convert certain numbers  
> to strings.  For example the number 5e-324 could legally be converted  
> as "3e-324", "4e-324", and so on up to "7e-324".
> 
> This would permit an implementation to evaluate the following  
> expression as "undefined":
> 
> ({5e-324:true})[5e-324]
> 
> I do not think any reasonable implementation would have a good reason  
> for doing this.
> 
> It also permits the value of 'a' to vary between implementations in  
> the following loop body:
> 
> for(a in {5e-324:true}) {...}
> 
> In order to ensure implementations all behave the same way I suggest  
> the note at end of section 9.8.1 be moved to normative status.  As  
> far as I can tell, the text is essentially the same between ECMA 262  
> 3rd edition and the Oslo draft published on 2008-07-04.
> 
> Cheers,
>   drj

I don't mind specifying it if the implementations agree.

Incidentally, this is a big problem with C and C++ right now.  gcc will 
generate code for 

  double x = ;
  double y = x;

  ...
  bool b1 = x == y;
  ...
  bool b2 = x == y;
  ...
  bool b3 = x == y;

where b1 and b3 will evaluate to true and b2 to false (the results depend on 
its register allocation strategy).

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

Two interoperable implementations rule

[Maciej Stachowiak]

On Jul 10, 2008, at 6:29 AM, [EMAIL PROTECTED] wrote:

In a message dated 7/10/2008 3:03:12 A.M. Eastern Daylight Time, [EMAIL PROTECTED] 
 writes:

I do not believe that ECMA has the "two interoperable implementations"
rule that the IETF and W3C have, but since ECMAScript is a standard of
equal important to the Web, I think we should adopt this rule for any
future edition of ECMAScript. Such a rule is needed precisely to avoid
such casual breakage relative to Web reality. Can we make that a
binding TC39 resolution?
While it is true that no such rule exists in Ecma, it has been used  
in work I am familiar with (optical storage) within TC 31.  Early  
work on MO storage resulted in TC 31 agreeing that at least two  
implementations must demonstrate interoperability before approval of  
the standard.  This meant that both disk manufacturers and drive  
manufacturers had to work together to demonstrate that the product  
resulting from the standard would work together.  The committee  
always followed this rule without question, and the CC and GA of  
Ecma did not interfere with its implementation.


We can add this subject to discussion at Oslo, but this is a  
question that I would put to an internal vote of TC 31 since it has  
wider impact than may be represented in Oslo.


Since there is precedent within ECMA, then I definitely think we  
should take a formal vote on adopting this rule for TC39, in  
particular that we must have two interoperable implementations for any  
of our specs before it progresses outside our committee.


There are also some details to be worked out:

1) Is "two interoperable implementations" at feature granularity, or  
whole spec granularity? In particular, is it ok to cite two  
implementations for one feature, but two other implementations for  
another?


2) How is interoperability to be demonstrated? Do we accept good-faith  
claims of support, or do we need a test suite?


Given the nature of programming languages and the high stakes of Web  
standards, I would personally prefer whole-spec granularity (different  
implementations having different mixes of features does not prove real  
interoperability), and a test suite rather than just bare claims of  
support.


To be clear, I propose this rule not to block ES3.1, but to make it  
successful. The WebKit project will accept patches for any feature of  
3.1 that  has been reconciled with 4, and we will likely devote Apple  
resources to implementing such features as well, so SquirrelFish will  
likely be a candidate for one of the interoperable implementations.  
Mozilla also has an extensive test suite for ECMAScript 3rd edition,  
which could be a good starting point for an ES3.1 test suite.


I also note that the strong version of the interoperable  
implementations rule will be an even higher hurdle for ES4.


Any comments?

Regards,
Maciej

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

Re: Two interoperable implementations rule

[Jeff Dyer]

On 7/11/08 3:01 PM, Maciej Stachowiak wrote:

> Since there is precedent within ECMA, then I definitely think we
> should take a formal vote on adopting this rule for TC39, in
> particular that we must have two interoperable implementations for any
> of our specs before it progresses outside our committee.

This proposal is in the spirit of what we have intended for ES4 all along.
Formalizing it seems to me to be a good idea. Will keep us honest anyway ;-)

> 
> There are also some details to be worked out:
> 
> 1) Is "two interoperable implementations" at feature granularity, or
> whole spec granularity? In particular, is it ok to cite two
> implementations for one feature, but two other implementations for
> another?

Very good point. I've always thought that "whole feature" was good enough,
but if our goal is defining a language for interoperability on the web then
"whole spec" seems to be the right choice.

> 2) How is interoperability to be demonstrated? Do we accept good-faith
> claims of support, or do we need a test suite?

I'd say that good faith is good enough. It's easy enough for us to check
each other's work. And the blogosphere will not be kind to liars.

One more detail: 

3) What constitutes a qualifying implementation? Does Rhino, EJScript
(mbedthis.com), or Flash Player qualify? Or must it be one of the four
leading browsers?

> Given the nature of programming languages and the high stakes of Web
> standards, I would personally prefer whole-spec granularity (different
> implementations having different mixes of features does not prove real
> interoperability), and a test suite rather than just bare claims of
> support.

Again, it will be hard to get away with cheating. But, on the other hand an
unofficial test suite (such as Spidermonkey's) would make it easier for
implementors to be honest.

> 
> To be clear, I propose this rule not to block ES3.1, but to make it
> successful. The WebKit project will accept patches for any feature of
> 3.1 that  has been reconciled with 4, and we will likely devote Apple
> resources to implementing such features as well, so SquirrelFish will
> likely be a candidate for one of the interoperable implementations.
> Mozilla also has an extensive test suite for ECMAScript 3rd edition,
> which could be a good starting point for an ES3.1 test suite.
> 
> I also note that the strong version of the interoperable
> implementations rule will be an even higher hurdle for ES4.

Yes, and one we've felt we should jump over all along. It would be good for
us to agree that standards produced by TC39 have all passed such a test. As
a consequence I suspect that our specs will have high rate of success.

Jd

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

Re: Two interoperable implementations rule

[Anne van Kesteren]

On Sat, 12 Jul 2008 00:01:26 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:
> To be clear, I propose this rule not to block ES3.1, but to make it
> successful. The WebKit project will accept patches for any feature of
> 3.1 that  has been reconciled with 4, and we will likely devote Apple
> resources to implementing such features as well, so SquirrelFish will
> likely be a candidate for one of the interoperable implementations.
> Mozilla also has an extensive test suite for ECMAScript 3rd edition,
> which could be a good starting point for an ES3.1 test suite.
>
> I also note that the strong version of the interoperable
> implementations rule will be an even higher hurdle for ES4.
>
> Any comments?

 From experience with other specifications, requiring two interoperable  
implementations does sound like a good idea. Especially if they are Web  
browsers so compatibility can be tested. It also means that once the  
specification ships authors can actually use it.


-- 
Anne van Kesteren


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

Re: Two interoperable implementations rule

[Brendan Eich]

On Jul 11, 2008, at 3:01 PM, Maciej Stachowiak wrote:



On Jul 10, 2008, at 6:29 AM, [EMAIL PROTECTED] wrote:

In a message dated 7/10/2008 3:03:12 A.M. Eastern Daylight Time,  
[EMAIL PROTECTED] writes:
I do not believe that ECMA has the "two interoperable  
implementations"
rule that the IETF and W3C have, but since ECMAScript is a  
standard of

equal important to the Web, I think we should adopt this rule for any
future edition of ECMAScript. Such a rule is needed precisely to  
avoid

such casual breakage relative to Web reality. Can we make that a
binding TC39 resolution?
While it is true that no such rule exists in Ecma, it has been  
used in work I am familiar with (optical storage) within TC 31.   
Early work on MO storage resulted in TC 31 agreeing that at least  
two implementations must demonstrate interoperability before  
approval of the standard.  This meant that both disk manufacturers  
and drive manufacturers had to work together to demonstrate that  
the product resulting from the standard would work together.  The  
committee always followed this rule without question, and the CC  
and GA of Ecma did not interfere with its implementation.


We can add this subject to discussion at Oslo, but this is a  
question that I would put to an internal vote of TC 31 since it  
has wider impact than may be represented in Oslo.


Since there is precedent within ECMA, then I definitely think we  
should take a formal vote on adopting this rule for TC39, in  
particular that we must have two interoperable implementations for  
any of our specs before it progresses outside our committee.


There are also some details to be worked out:

1) Is "two interoperable implementations" at feature granularity,  
or whole spec granularity? In particular, is it ok to cite two  
implementations for one feature, but two other implementations for  
another?


2) How is interoperability to be demonstrated? Do we accept good- 
faith claims of support, or do we need a test suite?


Given the nature of programming languages and the high stakes of  
Web standards, I would personally prefer whole-spec granularity  
(different implementations having different mixes of features does  
not prove real interoperability), and a test suite rather than just  
bare claims of support.


To be clear, I propose this rule not to block ES3.1, but to make it  
successful. The WebKit project will accept patches for any feature  
of 3.1 that  has been reconciled with 4, and we will likely devote  
Apple resources to implementing such features as well, so  
SquirrelFish will likely be a candidate for one of the  
interoperable implementations. Mozilla also has an extensive test  
suite for ECMAScript 3rd edition, which could be a good starting  
point for an ES3.1 test suite.


I also note that the strong version of the interoperable  
implementations rule will be an even higher hurdle for ES4.


Any comments?


You don't need another huzzah from me.

The hurdle is certainly higher for ES4, although it may be less high  
given its reference implementation, which could pass the tests.  
Should a reference implementation, even if slow, count?


Of course tests are never complete, but we need not pretend they are  
to have confidence in interoperation. I am interested in real  
programmers banging on "draft" implementations, which will produce  
bug reports beyond what tests find, and lead to more tests being  
developed.


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

Re: Two interoperable implementations rule

[Geoffrey Garen]

> Should a reference implementation, even if slow, count?

My own opinion on this is "no."

Since, for the most part, a reference implementation doesn't face the  
performance and maintainability challenges that shipping software  
faces, I don't think it fleshes out the same issues that a real-world  
implementation would.

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

Re: Two interoperable implementations rule

[Anne van Kesteren]

On Sat, 12 Jul 2008 00:54:05 +0200, Brendan Eich <[EMAIL PROTECTED]>  
wrote:
> The hurdle is certainly higher for ES4, although it may be less high
> given its reference implementation, which could pass the tests.
> Should a reference implementation, even if slow, count?

FWIW, a reference implementation misses a real important point of having  
implementations before finalizing, testing Web compatibility.


(Removed ES3 as I'm not subscribed.)


-- 
Anne van Kesteren


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

Re: Two interoperable implementations rule

[Maciej Stachowiak]

On Jul 11, 2008, at 3:49 PM, Jeff Dyer wrote:

>
> On 7/11/08 3:01 PM, Maciej Stachowiak wrote:
>
>> 2) How is interoperability to be demonstrated? Do we accept good- 
>> faith
>> claims of support, or do we need a test suite?
>
> I'd say that good faith is good enough. It's easy enough for us to  
> check
> each other's work. And the blogosphere will not be kind to liars.

I'm less concerned about cheating than about honest mistakes, which  
may nonetheless affect interoperability, Web compatibility, or  
practical implementability of the spec.

For the WebKit project, we always make our best effort to correctly  
implement Web standards, and even make our own test cases as we go.  
However, once an independently developed test suite appears it always  
finds mistakes in our implementation. I think we are not unusual in  
this regard.

> One more detail:
>
> 3) What constitutes a qualifying implementation? Does Rhino, EJScript
> (mbedthis.com), or Flash Player qualify? Or must it be one of the four
> leading browsers?

That is a good point to raise. I think limiting to browser-hosted  
implementations might be too extreme. On the other hand, if a spec  
qualifies based solely on non-browser-hosted implementations, then we  
have not done much to verify that the standard is compatible with the  
real-world Web. I think a reasonable middle ground would be to require  
at least one of the implementations to be browser-hosted. For these  
purposes, I would count an implementation that works as a browser  
extension replacing the scripting engine so long as it actually gets  
wide testing, so for example ScreamingMonkey could qualify.

It should also be required that the two implementations are  
independent (so a single vendor presenting two implementations would  
not qualify). This may be tricky to define, since many possible  
candidate implementations are open source and developed  
collaboratively by community contributors and overlapping sets of  
vendors. For example, would Rhino and SpiderMonkey count as  
sufficiently independent implementations?

>
>> Given the nature of programming languages and the high stakes of Web
>> standards, I would personally prefer whole-spec granularity  
>> (different
>> implementations having different mixes of features does not prove  
>> real
>> interoperability), and a test suite rather than just bare claims of
>> support.
>
> Again, it will be hard to get away with cheating. But, on the other  
> hand an
> unofficial test suite (such as Spidermonkey's) would make it easier  
> for
> implementors to be honest.

Again, I am less worried about cheating than mistakes. If we had a  
semi-official test suite, it would not be normative, only the spec is  
normative. It would only be a tool for verifying interoperability has  
been achieved to a reasonable degree. The concern is less about  
deliberate deception than about having at least the minimal evidence  
needed to make a fact-based claim.

Regards,
Maciej



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

Re: Two interoperable implementations rule

[Brendan Eich]

On Jul 11, 2008, at 4:06 PM, Geoffrey Garen wrote:


Should a reference implementation, even if slow, count?


My own opinion on this is "no."

Since, for the most part, a reference implementation doesn't face the
performance and maintainability challenges that shipping software
faces, I don't think it fleshes out the same issues that a real-world
implementation would.


I happen to agree, but this means there's more than a shared test  
suite in answer to Maciej's second question:


2) How is interoperability to be demonstrated? Do we accept good- 
faith claims of support, or do we need a test suite?


If only a test suite were enough, then the RI would have to count.

The chicken-and-egg problems with prototype implementations and draft  
specs suggest that we need all of tests, users banging on prototypes  
and causing new (reduced) tests to be written, and of course specs  
(ideally testable, which is the primary reason for the RI).


It will take nice judgment along with hard work to reach the point  
where we believe the specs should be standardized. It's clear some  
vendors won't want to risk implementing and shipping something that  
has not yet been standardized. I don't want to over-formalize at this  
point, but I'm happy to exclude the RI in the "Two interoperable  
implementations" rule.


/be

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

RE: Two interoperable implementations rule

[Allen Wirfs-Brock]

A few thoughts on the general topic and various points that are been raised:

Overall, I think this is a good idea.  My personal opinion is that 
standardization should follow proven utility, not the other way around.  
However, it's difficult to get meaningful use of proposed web standards until 
there is ubiquitous implementation. If we, as a community, can find a way to 
meaningfully work together to advance web technology it will be a very good 
thing.

Realistically, I think it has to be real browser-based implementations. 
However, Maciej's at least one browser implementation suggestion may be good 
enough. My perception is that we have far more unresolved "will it break the 
web" arguments then we do about the actual utility of features.  Let's just 
demonstrate it on the web, one way or another.  BTW, I think this puts us 
(Microsoft) at a disadvantage because we have self imposed restrictions that 
currently make it much harder for us to publicly demonstrate (or even discuss) 
browser changes or enhances than it would be for any sort of standalone 
implementation we did. We'll have to learn how to deal with it.

Conversely, I don't think a "reference implementation" really makes the cut, 
even if it is hosted in a browser.  However, there isn't necessarily a sharp 
line between a reference implementation and a simplistic or naïve "production" 
implementation so maybe the browser hosted requirement is as close as we can 
come to pinning that down.

I'm ambivalent on the single feature or entire specification question. For a 
spec. on the order what is being proposed as ES3.1 I don't think an entire 
spec. requirement would be unreasonably burdensome.  For more complex feature 
sets I'm less sure.  A related question is what does it take for a feature to 
even get into a proposed specification? You can't require complete 
implementation of a spec. that is not yet complete.  Is a public, browser based 
implementation a pre-requisite for even getting to the state of a feature 
proposal? I could argue both sides of that one.

Feature interactions are often a source of unanticipated problems.  That argues 
for testing an entire specification.

Is there a time limit in which implementations must occur?  How do we actually 
reach the point of "shipping" a revised specification.

An implementation, without some way to validate it seems of limited use.  
Should we also expect those who propose features to also provide a validation 
suite?

How fine a granularity do we push this to. Some of the sorts of clarify changes 
to existing specification language or changes to specification models that are 
needed to accommodate new features may not even be directly testable if their 
intent is no net change to the existing feature set.

Don't take this a "vote" yet, as we certainly need to have some internal 
discussion on the topic.  However, I don't see how such a requirement would be 
in any way inconsistent with how Microsoft currently thinks about the process 
of web evolution.

Allen

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

Re: Two interoperable implementations rule

[Maciej Stachowiak]

On Jul 11, 2008, at 5:03 PM, Allen Wirfs-Brock wrote:

> A few thoughts on the general topic and various points that are been  
> raised:
>
> Overall, I think this is a good idea.  My personal opinion is that  
> standardization should follow proven utility, not the other way  
> around.  However, it's difficult to get meaningful use of proposed  
> web standards until there is ubiquitous implementation. If we, as a  
> community, can find a way to meaningfully work together to advance  
> web technology it will be a very good thing.
>
> Realistically, I think it has to be real browser-based  
> implementations. However, Maciej's at least one browser  
> implementation suggestion may be good enough. My perception is that  
> we have far more unresolved "will it break the web" arguments then  
> we do about the actual utility of features.  Let's just demonstrate  
> it on the web, one way or another.  BTW, I think this puts us  
> (Microsoft) at a disadvantage because we have self imposed  
> restrictions that currently make it much harder for us to publicly  
> demonstrate (or even discuss) browser changes or enhances than it  
> would be for any sort of standalone implementation we did. We'll  
> have to learn how to deal with it.

There are a few purposes for requiring interoperable implementations  
to advance the specification:

1) Demonstrate practical implementability - that the spec can be  
implemented correctly in a production-quality implementation without  
truly excessive implementation effort.
2) Show that the spec can be implemented without compromising Web  
compatibility, through implementor review and widespread testing.
3) Help flush out performance, security and usability issues through  
implementation and use of the resulting implementations.
4) Show that the spec language is unambiguous enough that multiple  
independent implementations are compatible.

A reference implementation, even if browser-hosted, would have limited  
utility for purposes 1 and 3 (since by definition it does not aim to  
be production-quality or high-performance). It may still help with  
goal #2 a lot if browser-hosted.

> Conversely, I don't think a "reference implementation" really makes  
> the cut, even if it is hosted in a browser.  However, there isn't  
> necessarily a sharp line between a reference implementation and a  
> simplistic or naïve "production" implementation so maybe the browser  
> hosted requirement is as close as we can come to pinning that down.
>
> I'm ambivalent on the single feature or entire specification  
> question. For a spec. on the order what is being proposed as ES3.1 I  
> don't think an entire spec. requirement would be unreasonably  
> burdensome.  For more complex feature sets I'm less sure.  A related  
> question is what does it take for a feature to even get into a  
> proposed specification? You can't require complete implementation of  
> a spec. that is not yet complete.  Is a public, browser based  
> implementation a pre-requisite for even getting to the state of a  
> feature proposal? I could argue both sides of that one.

I think it would be overkill to require an implementation (or even a  
test suite) to even make a proposal. We should expect that at some  
point in the standards development process, there will be a cycle of  
feedback among implementations and the spec, where implementors  
identify problems and propose changes, and the spec is adapted as a  
result.

The IETF and W3C, the two other major standards organizations that  
operate in the area of Web and Internet standards, have a two  
implementation rule combined with a sequence of maturity levels. Here  
is a summary of their levels:


IETF :

* Internet-Draft -- Initial published version, for comment and review  
(typically there are multiple iterations as an Internet-Draft, the  
minimum comment period is 2 weeks)

* Proposed Standard --  Has resolved known design choices, is believed  
to be well-understood, has received significant community review. But  
further experience might result in a change or even retraction of the  
specification before it advances. This is the stage at which wide  
implementation is encouraged. Minimum 6 month duration.

* Draft Standard -- Two independent and interoperable implementations  
from different code bases have been developed. Well-understood and  
known to be quite stable. Minimum 4 month duration.

* Internet Standard -- Characterized by a high degree of technical  
maturity and by a generally held belief that the specified protocol or  
service provides significant benefit to the Internetcommunity.  
(Not all implementations reach this stage.)

(There is also a minimum 2 week Last Call period between any state  
transition.)


W3C :

* Working Draft -- A signal to the community to begin reviewing the  
document. (Typically multiple iterat

Re: Proposed ES4 draft 2

[Eric Suen]

Hi,

Since FunctionExpression is PrimaryExpression, so the following statement:

a = function() return b ? c : d;

should be:

a = fe ? c : d
fe = function() return b

or

a = fe
fe = function() return b ? c : d

And same question for LetExpression.

Regards,

Eric Suen

- Original Message - 
From: "Jeff Dyer" 
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: "TC39" <[EMAIL PROTECTED]>; 
<[EMAIL PROTECTED]>
Cc: "Patrick Charollais" 
<[EMAIL PROTECTED]>
Sent: Saturday, July 12, 2008 7:59 AM
Subject: Proposed ES4 draft 2


> Enclosed is an update to the draft ES4 specs. This includes revisions of the
> introduction, grammar and core-language specs of draft 1 (16-May) as well as
> an initial draft of the library spec.
>
> Also included are files that show the differences between draft 1 and draft
> 2 specs. There have been substantial changes to the text of the
> core-language spec and so the difference file for that spec is quite noisy.
> Two changes that contribute significantly to the noise are the renaming of
> "rib" to "fixture map", and the simplification of the name resolution
> algorithms (in particular reducing the required number of search passes from
> two to one).
>
> These specs should be the basis for technical discussions of ES4 on
> es4-discuss and at the July 23 Oslo meeting.
>
> Enjoy!
>
> Jd
>
> [Patrick, please assign appropriate document numbers and post to the
> internal TC39 repository. Thanks!]
>
>





> ___
> Es4-discuss mailing list
> [EMAIL PROTECTED]
> https://mail.mozilla.org/listinfo/es4-discuss
> 


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

Re: Proposed ES4 draft 2

[Garrett Smith]

2008/7/11 Jeff Dyer <[EMAIL PROTECTED]>:


> These specs should be the basis for technical discussions of ES4 on
> es4-discuss and at the July 23 Oslo meeting.
>

What about operators:
  &&=
  ||=

?

Garrett

>
> Jd
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss