On March 04, 2010 11:07 AM, Brendan Eich wrote:
Right. I was explicit about hypothesizing an ecosystem solution,
independent of the standard and predicated on fast JS engines. This is
not meant to preempt your great work making RegExp incrementally better.
We (by which I mean "you" with edit
On March 04, 2010 11:40 AM, Andy Chu wrote:
Regarding "RegEx", I'm pretty certain Brendan was talking about a
hypothetical new library (name unimportant) that the JavaScript community
might create in the future. I don't think anyone has suggested adding a
I worked on something like this:
http:
Chopping up your replies a bit...
On March 03, 2010 10:28 AM, Andy Chu wrote:
I agree that Perl has useful stuff that JavaScript doesn't have. But
it's a slippery slope because even Perl 6 has admitted that Perl 5
regexes got out of hand. [...]
It's a hard problem, because adding power and kee
On February 23, 2010 8:50 AM, Andy Chu wrote:
So now that Erik Corry pointed out that /y as a compilation option
matches the implementation, as mentioned I don't mind leaving it out
of the method parameters. The "pos" is the one that still should be a
method argument.
[...]
/y works for me. I
On Feb 17, 2010, at 12:45 AM, Brendan Eich wrote:
I think \G without full Perl compatibility is less desirable than /y --
but I would want some solution here, and it should be on the Harmony
agenda.
Prior to and after this discussion (I wavered a bit in the middle), I'm
inclined to agree wi
On Feb 14, 2010, at 1:40 AM, Brendan Eich wrote:
compatibility with other regex flavors is probably good enough reason to
chose \G over /y.
Not clear, since ES3 deviated from Perl and will not reconverge. The
committee is not going to standardize any lastIndex or pos mapping per
target stri
2010/2/12 Erik Corry :
Agree that \G breaks some logical barrier. I like to have a mental
model of the implementation internals, and \G breaks that a bit.
\G is more flexible and it is rather similar to ^ conceptually.
The mental model happens to be out of sync with how regexps are
implement
2010/2/12 Andy Chu :
Agree that \G breaks some logical barrier. I like to have a mental
model of the implementation internals, and \G breaks that a bit.
If compatibility with Mozilla is not an issue, I actually prefer
Python's approach of .search() vs. .match(). It's not a part of the
regex;
sif ($html =~ /\G<(\w+)[^>]+>/gc) {
...
} elsif ($html =~ /\G&#?\w+;/gc) {
...
}
}
Sorry for the tangent, but I thought it might be helpful to describe how \G
is used elsewhere.
Steven Levithan
http://blog.stevenlevithan.com
-------
http://andychu.net/ecmascript/RegExp-Enhancements-2.html
Basically the proposal is to add parameters which can override the
internal state of the RegExp.
Does anyone have any comments on this?
Can I put it in a place where it will be considered for the next
ECMAScript? The overall idea seem
It may be beneficial to clarify in the ES5 spec that searches should take
place and lastIndex should be updated based on a copy of the value of
lastIndex made at the start of String#replace's processing. If you follow
the dependency chain--where String#replace relies on the definition of
String
It may be beneficial to clarify in the ES5 spec that searches should take
place and lastIndex should be updated based on a copy of the value of
lastIndex made at the start of String#replace's processing. If you follow
the dependency chain--where String#replace relies on the definition of
String
I noticed in the ECMA 5 draft that String#replace references
String#match's handling of regexp.lastIndex
when the regexp is flagged global. According to the draft String#match
sets the regexp.lastIndex when the regexp is global.
All of this is identical to ECMA-262 Edition 3.
Currently Firefox
13 matches
Mail list logo
