On Thu, Jan 8, 2009 at 9:30 PM, Brendan Eich wrote:
>
> The rationale "we dare not break" applies to other cases of making the
> strict mode migration tax too high. This came up in the wiki just now, and
> I've commented in-line at
>
> http://wiki.ecmascript.org/doku.php?id=meetings:minutes_dec_1
2009/1/8 Mark S. Miller :
> (I'm dangerously
> ignoring here the distinction between primitives and wrappers. In fact, in
> ES3 and ES3.1, "e instanceof Number" is false. Fixing the strawman
> accordingly presents no problems but makes it tedious. I will continue
> ignoring this for now.)
I meant
On Jan 8, 2009, at 9:27 PM, Mark S. Miller wrote:
On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich
wrote:
[lots of agreement]
Wonderful!
Generic programming with primtiives more often wants to *read*
undefined when getting a non-existent property, and "object detect"
without having to try/c
On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich wrote:
> [lots of agreement]
Wonderful!
> Generic programming with primtiives more often wants to *read* undefined
> when getting a non-existent property, and "object detect" without having to
> try/catch. This common use case is not served by stri
HI Mark,
The fix of allowing primitive Reference base type is ok for
implementations such as SpiderMonkey, which already does this for the
built-in methods on String.prototype, Number.prototype, and
Boolean.prototype to avoid the overhead of wrappers when calling
native methods on string,
First, let me acknowledge that there's been a long history of attempts to
add operator overloading to EcmaScript, that these have all died for various
reasons leaving much documentation in its wake, and that I have not read
this documentation at the present time. If I am simply rehashing ideas whic
Currently, according to the draft ES3.1 spec
String.prototype.reverse = function() {
"use strict";
if (this === '') { return this; }
return this.substring(1).reverse() + this.charAt(0);
};
String.prototype.reverse.call("hello") // 1) works
"hello".reverse.call("h
On Thu, Jan 8, 2009 at 8:57 AM, Dave Herman wrote:
> [NB: I agree with Mark that we should not focus too much on concrete syntax
> yet, so I'll also plead for people to avoid quibbling with details of syntax
> for the moment.]
>
> Instead of "reveal" I'd prefer block expressions with a fixed (but
[NB: I agree with Mark that we should not focus too much on concrete
syntax yet, so I'll also plead for people to avoid quibbling with
details of syntax for the moment.]
Instead of "reveal" I'd prefer block expressions with a fixed (but
optional) tail expression:
BlockExpr ::= "{" (Stmt|
9 matches
Mail list logo
