Le 07/07/2011 13:11, Tom Van Cutsem a écrit :
2011/7/6 Andreas Rossberg rossb...@google.com
mailto:rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the
On 7 July 2011 13:11, Tom Van Cutsem tomvc...@gmail.com wrote:
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
It seems
Le 07/07/2011 14:29, Andreas Rossberg a écrit :
On 7 July 2011 13:11, Tom Van Cutsemtomvc...@gmail.com wrote:
2011/7/6 Andreas Rossbergrossb...@google.com
It seems like a reasonable assumption, but is not currently the case
everywhere (e.g. the default implementation for `keys' can violate
On 7 July 2011 14:32, David Bruant david.bru...@labri.fr wrote:
However, if we assume that the getOwnPropertyNames trap is able to do type
coercion on its output, there is no reason for the keys trap to not do that
too, regardless of how it was implemented.
Yes, that's what I would propose,
Le 07/07/2011 14:40, Andreas Rossberg a écrit :
On 7 July 2011 14:32, David Bruantdavid.bru...@labri.fr wrote:
However, if we assume that the getOwnPropertyNames trap is able to do type
coercion on its output, there is no reason for the keys trap to not do that
too, regardless of how it was
On 7 July 2011 15:09, David Bruant david.bru...@labri.fr wrote:
Yes, that's what I would propose, too. It's just a bit ugly that we
have to do that in two places now.
Three if counting the enumerate trap for for-in loops. Regardless of
ugliness, it's necessary. keys and enumerate are derived
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name objects, right?
Dave
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish internally as long as the observed
behavior is the same.
True, but optimizing that actually is more tricky than you
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish internally as long as the observed
behavior is the same.
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish
Le 07/07/2011 18:05, Andreas Rossberg a écrit :
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Le 07/07/2011 18:24, David Bruant a écrit :
Le 07/07/2011 18:05, Andreas Rossberg a écrit :
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only one at
the exit of the keys trap. There would be 2 conversions if the keys
trap had the proxy argument (based on
2011/7/7 Lasse Reichstein reichsteinatw...@gmail.com:
On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel mikesam...@gmail.com wrote:
Yes, by the extension, and whether a \octal is a backreference or an
octal escape sequence is determined by whether there are
parseInt(octal, 10) capturing groups to
2011/7/7 Mike Samuel mikesam...@gmail.com:
Interestingly other perl 5 interpreters
other perl 5 interpreters - other perl 5 style regex libraries
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
CC'ing Gavin as he's been looking at RegExp compatibility in the real world vs.
the spec recently.
--Oliver
On Jul 7, 2011, at 12:17 PM, Mike Samuel wrote:
2011/7/7 Lasse Reichstein reichsteinatw...@gmail.com:
On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel mikesam...@gmail.com wrote:
The discussion of parser APIs had a side-thread on language
versioning which I'd like to raise separately, for those not
following the parser discussions. I include the relevant
context, then continue the thread below.
But there are also tough questions about what the parser
should do with
On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel mikesam...@gmail.com
wrote:
One way to tell whether the group initialized to empty works on an
interpreter is to test
/^(?:\1x(y)x){2}$/.test(xyxyxyx)
which is true in most interpreters, but false in Rhino1.7 and Chrome12.
I do believe it
Le 07/07/2011 20:52, Andreas Rossberg a écrit :
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only one at
the exit of the keys trap. There would be 2 conversions if the
On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote:
On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel mikesam...@gmail.com wrote:
One way to tell whether the group initialized to empty works on an
interpreter is to test
/^(?:\1x(y)x){2}$/.test(xyxyxyx)
which is true in most interpreters,
On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote:
On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel
One way to tell whether the group initialized to empty works on an
interpreter is to test
/^(?:\1x(y)x){2}$/.test(xyxyxyx)
which is true in most interpreters, but false in Rhino1.7 and
2011/7/7 Brendan Eich bren...@mozilla.com:
On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote:
On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel mikesam...@gmail.com wrote:
One way to tell whether the group initialized to empty works on an
interpreter is to test
Hi everyone, the test case improvements I alluded to last week have all been
checked in and updated on the live website. Enabling previously invalid tests
and disabling recently reported invalid tests amounted to a net gain of eleven
tests for the entire suite. Also, worth mentioning is
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
Agreed.
Would that mean that
/^(?:\1x(y)x){2}$/.test(xyxxyx) !/^(?:\1x(y)x){2}$/.test(xyxyxyx)
If so, V8 agrees with that, the species of monkey in FF 5 does not,
the JsCore in Safari 533.21 does not, and Rhino does.
Yes. This is
2011/7/7 Gavin Barraclough barraclo...@apple.com:
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
Agreed.
Would that mean that
/^(?:\1x(y)x){2}$/.test(xyxxyx) !/^(?:\1x(y)x){2}$/.test(xyxyxyx)
If so, V8 agrees with that, the species of monkey in FF 5 does not,
the JsCore in Safari
On Jul 7, 2011, at 3:27 PM, Gavin Barraclough wrote:
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
Agreed.
Would that mean that
/^(?:\1x(y)x){2}$/.test(xyxxyx) !/^(?:\1x(y)x){2}$/.test(xyxyxyx)
If so, V8 agrees with that, the species of monkey in FF 5 does not,
the JsCore in
On Jul 7, 2011, at 3:34 PM, Mike Samuel wrote:
2011/7/7 Gavin Barraclough barraclo...@apple.com:
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
Agreed.
Would that mean that
/^(?:\1x(y)x){2}$/.test(xyxxyx) !/^(?:\1x(y)x){2}$/.test(xyxyxyx)
If so, V8 agrees with that, the species
Hi Mark,
In the harmony classes proposal,
http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in
understanding the following issue:
One or two namespaces for public properties and private instance
variables [RESOLVED two, Mark’s argument]
Do you remember if this
28 matches
Mail list logo
