Re: Public/private namespaces in harmony classes proposal

On Jul 7, 2011, at 11:15 PM, Brendan Eich wrote: >> Suppose I have two objects, extensible instance X with private instance >> property 'foo', and extensible object Y upon which I have defined a property >> 'foo' using Object.defineProperty, setting writable=false. If a client of Y >> tries to

Re: Public/private namespaces in harmony classes proposal

On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote: > Ah, I see. It's a fair point, but isn't this already a hazard that the > language faces? Not with private names. > Suppose I have two objects, extensible instance X with private instance > property 'foo', and extensible object Y upon wh

Re: Public/private namespaces in harmony classes proposal

On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote: > > On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough > wrote: > 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

Re: Public/private namespaces in harmony classes proposal

On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough wrote: > 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 > v

Public/private namespaces in harmony classes proposal

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 ar

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

On Jul 7, 2011, at 3:34 PM, Mike Samuel wrote: > 2011/7/7 Gavin Barraclough : >> 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, t

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

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 n

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

2011/7/7 Gavin Barraclough : > 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

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

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

RE: test262 Update

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 there'

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

2011/7/7 Brendan Eich : > On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote: > >> On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel 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

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

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 Rh

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote: > On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel 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

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 20:52, Andreas Rossberg a écrit : > On 7 July 2011 19:35, David Bruant 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" >>> t

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel 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 should be false. Th

feature-based and compartment-based language versioning (was: JavaScript parser API)

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 engin

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

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 : >> >> >> On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel wrote: >>> >>> Yes, by the extension, and whether a

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

2011/7/7 Mike Samuel : > 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

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

2011/7/7 Lasse Reichstein : > > > On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel wrote: >> >> Yes, by the extension, and whether a \ is a backreference or an >> octal escape sequence is determined by whether there are >> parseInt(, 10) capturing groups to the left of it in the >> regular expression.

Re: Type of property names, as seen by proxy traps

On 7 July 2011 19:35, David Bruant 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 >> http://wiki.ec

Re: Type of property names, as seen by proxy traps

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 wrote: >>> On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote: >>> On 7 July 2011 16:12, David Bruant wrote: >>> Derived traps as showed are written in JS f

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 18:05, Andreas Rossberg a écrit : > On 7 July 2011 17:58, Brendan Eich wrote: >> On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote: >> >>> On 7 July 2011 16:12, David Bruant wrote: >> Derived traps as showed are written in JS for expository purposes. >> Engines >> will

Re: Type of property names, as seen by proxy traps

On 7 July 2011 17:58, Brendan Eich wrote: > On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote: > >> On 7 July 2011 16:12, David Bruant 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 t

Re: Type of property names, as seen by proxy traps

On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote: > On 7 July 2011 16:12, David Bruant 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. >>> >>> Tr

Re: Type of property names, as seen by proxy traps

On 7 July 2011 16:12, David Bruant 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 might

Re: Type of property names, as seen by proxy traps

> 2011/7/6 Andreas Rossberg > 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 ___

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 15:42, Andreas Rossberg a écrit : On 7 July 2011 15:09, David Bruant 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

Re: Type of property names, as seen by proxy traps

On 7 July 2011 15:09, David Bruant 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 traps. They h

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 14:40, Andreas Rossberg a écrit : On 7 July 2011 14:32, David Bruant 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'

Re: Type of property names, as seen by proxy traps

On 7 July 2011 14:32, David Bruant 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, too. It's just a bi

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 14:29, Andreas Rossberg a écrit : On 7 July 2011 13:11, Tom Van Cutsem wrote: 2011/7/6 Andreas Rossberg It seems like a reasonable assumption, but is not currently the case everywhere (e.g. the default implementation for `keys' can violate this assumption when passing names to th

Re: Type of property names, as seen by proxy traps

On 7 July 2011 13:11, Tom Van Cutsem wrote: > 2011/7/6 Andreas Rossberg >> >> 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 like a reasonable assumpti

Re: Type of property names, as seen by proxy traps

Le 07/07/2011 13:11, Tom Van Cutsem a écrit : 2011/7/6 Andreas Rossberg > 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 l

Re: Type of property names, as seen by proxy traps

2011/7/6 Andreas Rossberg > 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 like a reasonable assumption, but is not currently the case > everywhere (e.g. the

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel wrote: > Yes, by the extension, and whether a \ is a backreference or an > octal escape sequence is determined by whether there are > parseInt(, 10) capturing groups to the left of it in the > regular expression. > So >/\1(foo)\1/ > matches the same