On Wed, Jan 19, 2011 at 10:58 PM, Mark S. Miller wrote:
> On Wed, Jan 19, 2011 at 10:06 PM, Brendan Eich wrote:
>
>> On Jan 19, 2011, at 5:23 PM, Waldemar Horwat wrote:
>>
>> MarkM: If we're making a harmonizer, let's get rid of semicolon
>> insertion as well.
>>
>>
>> For the record, I argued t
On Wed, Jan 19, 2011 at 10:06 PM, Brendan Eich wrote:
> On Jan 19, 2011, at 5:23 PM, Waldemar Horwat wrote:
>
> MarkM: If we're making a harmonizer, let's get rid of semicolon
> insertion as well.
>
>
> For the record, I argued that we have only a handful of fingers to count
> breaking changes i
On Jan 19, 2011, at 5:23 PM, Waldemar Horwat wrote:
> MarkM: If we're making a harmonizer, let's get rid of semicolon
> insertion as well.
For the record, I argued that we have only a handful of fingers to count
breaking changes in Harmony. Trying for more risks not agreeing in TC39, or
should
On Wed, Jan 19, 2011 at 20:23, Mark S. Miller wrote:
> On Wed, Jan 19, 2011 at 5:02 PM, Nebojša Ćirić wrote:
>>
>> Eric proposed to remove the derive method from all API objects and do
>> something like this:
>> var loc = new LocaleInfo({}); // {...} are the options we construct
>> LocaleInf
On Wed, Jan 19, 2011 at 5:02 PM, Nebojša Ćirić wrote:
> Eric proposed to remove the derive method from all API objects and do
> something like this:
>
> var loc = new LocaleInfo({}); // {...} are the options we construct
> LocaleInfo object with.
> var opt2 = loc.options; // This returns a
The list didn’t like my email address…, trying again.
From: Shawn Steele
Sent: Poʻakolu, Ianuali 19, 2011 6:12 hours
To: 'Nebojša Ćirić'; es-discuss@mozilla.org
Subject: RE: 2nd day meeting comments on the latest i18n API proposal
I think a “common” case is to tweak a part of a LocaleInfo object,
Here are my rough notes for today's meeting.
Waldemar
--
Internationalization standard: Part of E262 or separate track? Pros
and cons to each one, and either would be workable. There is a
substantial area of interaction (ES5 locale methods, normalization,
and such) between them
Eric proposed to remove the derive method from all API objects and do
something like this:
var loc = new LocaleInfo({}); // {...} are the options we construct
LocaleInfo object with.
var opt2 = loc.options; // This returns a copy of options from loc object.
opt2.currency = "USD";
var loc2 =
On Wed, Jan 19, 2011 at 2:13 PM, Erik Corry wrote:
> 2011/1/19 Dave Fugate :
> > I’ve come across the following RegExp scenario:
> >
> > /\s^/m.test("\n")
> >
> >
> >
> > which results in true, yet the equivalent in Perl 5:
> >
> > "\n" =~ m/\s^/m
> >
> >
> >
> > yields false.
> >
2011/1/19 Dave Fugate :
> I’ve come across the following RegExp scenario:
>
> /\s^/m.test("\n")
>
>
>
> which results in true, yet the equivalent in Perl 5:
>
> "\n" =~ m/\s^/m
>
>
>
> yields false.
>
>
>
> It seems that the JavaScript implementations I tested against are correctly
I've come across the following RegExp scenario:
/\s^/m.test("\n")
which results in true, yet the equivalent in Perl 5:
"\n" =~ m/\s^/m
yields false.
It seems that the JavaScript implementations I tested against are correctly
implementing ES5. That is, 15.10.2.6, step 4 states t
2011/1/19 Cormac Flanagan :
> On Mon, Jan 10, 2011 at 2:12 AM, Erik Corry wrote:
>> On the concrete proposal I note that the strawman claims this can be
>> used to implement bignums, but it seems to me there is no way to
>> implement storage of arbitrary size so that would appear to be
>> impossib
On Sun, Jan 9, 2011 at 12:41 PM, Jürg Lehni wrote:
> The mention of the term made me wonder: Is it wrong to dream of JavaScript
> with operator overloading?
Hi Jürg,
There is strawman proposal along these lines that should fulfill your
use cases. See
http://wiki.ecmascript.org/doku.php?id=stra
On Mon, Jan 10, 2011 at 2:12 AM, Erik Corry wrote:
> On the concrete proposal I note that the strawman claims this can be
> used to implement bignums, but it seems to me there is no way to
> implement storage of arbitrary size so that would appear to be
> impossible. Am I missing something.
The
On Sun, Jan 9, 2011 at 11:51 PM, thaddee yann tyl wrote:
> I see no reason to name the "floordiv" trap that way. Python has a
> good reason: they have more than one division operator (/ and //).
> The reason for it is that, at the beginning, the division operator
> behaved just like that of C: 1/2
http://www.google.com/search?q=lookbehind+es-discuss
2011/1/19 Corey Hart :
> Just curious if there has been any discussion on supporting lookbehind in
> regular expressions. Seems strange that there is no support since lookaheads
> are
> supported(https://mail.mozilla.org/pipermail/es-discuss/200
Just curious if there has been any discussion on supporting lookbehind in
regular expressions. Seems strange that there is no support since lookaheads
are
supported(https://mail.mozilla.org/pipermail/es-discuss/2009-February/008719.html).___
es-discuss
17 matches
Mail list logo
