Re: Regex: How should backreferences contained in the capturing match they reference to work?

I am not looking to make trouble here, believe me, but I want to point out two things that could help David's case: 1. JS regexps were modeled by me (to lwall's horror ;-) on Perl regexen. Here's what perl (5.8.8) does: $ perl "aaab" =~ /(a\1)+|b/; print "$& ($1)\n"; b () It's no surprise Ja

Re: catch-if syntax?

On Sep 13, 2007, at 7:23 PM, Dominic Cooney wrote: > I notice that the normative grammar* doesn't mention SeaMonkey's catch > (identifier if expr) syntax for filtering exceptions. Is that > deliberate? Yes, that was a SpiderMonkey (not SeaMonkey, n.b.; it may also be supported in Rhino) extensi

catch-if syntax?

I notice that the normative grammar* doesn't mention SeaMonkey's catch (identifier if expr) syntax for filtering exceptions. Is that deliberate? Dominic * http://www.ecmascript.org/es4/spec/grammar.pdf ___ Es4-discuss mailing list Es4-discuss@mozilla.or

Re: Regex: How should backreferences contained in the capturing match they reference to work?

On 9/13/07, liorean <[EMAIL PROTECTED]> wrote: > On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote: > > The current behavior > > is well-defined; it's not a hardship for anyone; the incompatibilities > > among the engines are probably not a big deal (thus the incompatible > > engines can be ch

Re: Regex: Named groups/backreferences

Ah, just the answers I wanted to hear:) -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss

Re: Regex: How should backreferences contained in the capturing match they reference to work?

On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote: > My answer to you is obviously that you should implement the ES3 > behavior (as should JScript and JavaScriptCore). Of course I'll implement the ES3 behaviour if ES4 makes no change to it, I just think it would be better to change the behavi

Re: Regex: Named groups/backreferences

On 9/13/07, liorean <[EMAIL PROTECTED]> wrote: > Hello! > > Got some questions about named groups: > > "Group names must be valid lexical identifiers, and each group name > must be defined only once within a regular expression." > > 1. Is this meant to indicate that regex add their own lexical scop

Re: Regex: How should backreferences contained in the capturing match they reference to work?

It is true that named submatches are just aliases for numbered submatches. My argument was only that programmers are vastly less likely to nest a named backreference inside the capturing submatch of that name than they are when the backreference is a number, because it will be much more obvious wh

Regex: Named groups/backreferences

Hello! Got some questions about named groups: "Group names must be valid lexical identifiers, and each group name must be defined only once within a regular expression." 1. Is this meant to indicate that regex add their own lexical scopes; partake in the lexical scope of their containing functio

Re: Regex: How should backreferences contained in the capturing match they reference to work?

Sorry for delaying my response on this. Wanted to get some public opinions on it: http://web-graphics.com/2007/09/05/a-quick-js-quizz-for-anybody-who-think-they-know-regex/> Sadly I only got responses from two developers, but they both seem to agree with me (and I was careful to not state my opini

Re: URI Proposal

Just one quick word: be careful when designing a URI class that it should be able to deal with URNs, too. Cheers, David On Fri, 2007-09-07 at 14:29 -0700, Garrett Smith wrote: > I've decided to propose a URI class to deal with the handling of URIs > that is so prevalent in Ajax apps and also in

Re: __proto__

On Tue, 2007-09-11 at 13:47 -0700, Kris Zyp wrote: > > > __proto__ breaks abstraction boundaries in the language -- > it's just > > Hiding for the sake abstraction is more valuable than introspective > visibility? I disagree, at least with JavaScript, IMHO JS's > introspective n