RegExp.test() funkiness (fails every second call)

[jasonkester]

Just a heads up for anybody that comes across this in the future.

Noticed a strange behavior in RegExp.test() today. Check out the
following code. It will alternately display "chokes" and null, as
every second call to .test() fails.

<script>
var str = "RegExp (chokes) on this every 2nd time";
var re = /chokes/g;

for (var a=0; a<10; a++)
{
alert(re.exec(str));
}
</script>
Remove the "g" from the end of the RegExp and it works as expected.
The "g" switch instructs the regex to perform global matching, which
shouldn't affect the testing for a single run. Anybody care to venture
an explaination for why this might have the demonstrated effect?
Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

[Vic Sowers]

<ja*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Just a heads up for anybody that comes across this in the future.

Noticed a strange behavior in RegExp.test() today. Check out the
following code. It will alternately display "chokes" and null, as
every second call to .test() fails.

<script>
var str = "RegExp (chokes) on this every 2nd time";
var re = /chokes/g;

for (var a=0; a<10; a++)
{
alert(re.exec(str));
}
</script>
Remove the "g" from the end of the RegExp and it works as expected.
The "g" switch instructs the regex to perform global matching, which
shouldn't affect the testing for a single run. Anybody care to venture
an explaination for why this might have the demonstrated effect?
Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

From the Windows Script Technologies help file:

If the global flag is set for a regular expression, exec searches the string
beginning at the position indicated by the value of lastIndex. If the global
flag is not set, exec ignores the value of lastIndex and searches from the
beginning of the string.

[Lasse Reichstein Nielsen]

ja*********@gmail.com writes:

It will alternately display "chokes" and null, as
every second call to .test() fails.

<script>
(should have type="text/javascript" attribute :)
var str = "RegExp (chokes) on this every 2nd time";
var re = /chokes/g;
for (var a=0; a<10; a++)
{
alert(re.exec(str));
} Remove the "g" from the end of the RegExp and it works as expected.
As some people would expect, yes (but not the ones who have read the
ECMAScript specification (and remembers it, that's the hard part :) )
The "g" switch instructs the regex to perform global matching, which
shouldn't affect the testing for a single run.
It should. This is what allows you to do global matching in steps, with
computation in between, e.g.:
---
var string = "balabaliolopaliouliap";
var re = /[aeiou]/g;
var match;
var count = {};
while(match = re.exec(string)) {
var vowel = match[0];
count[vowel] = (count[vowel] || 0) + 1;
alert("Vowel "+vowel+" found at index " + (re.lastIndex));
}
---
Anybody care to venture an explaination for why this might have the
demonstrated effect?

Because a call to RegExp.prototype.exec with a regular expression with
the global flag set will start matching from the regexp's current
value of lastIndex - the index of the previous match. Only when the
exec fails to do a match will lastIndex be reset to 0.

You can add a line:
re.lastIndex = 0;
before each call, if you only want to find the first match.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[vallini]

===
(should have type="text/javascript" attribute :)
===

In order to validate for the w3c parser. But only in order for that.
For the rest it will work, also if failing validation, no human will
ever notice, no browser will ever complain, no version of browsers will
fail to understand it.
This at least until that very happy day shall come when a browser will
FINALLY utterly refuse to parse a script because it lacks the type, and
shall send all awry in the name of w3c strict validation. Till that
very very happy time, we can omit it with sheer awful impunity and go
to no jail despite the abominable crime LOL :-)

Ah yeah, spreading good programming practice & "quality assurance"...
right I forgot :-)

ps no ad personam/hominem/guy provocation meant, really. It's just that
with all these pages failing validation for these nuisances, we at
times get the impression that when dealing wsith the w3c parsers we are
like Romeo and Juliet in Shakespeare:

===
peace, peace, mercutio, peace! thou talk'st of nothing.
===

No type parser, no type; failed validation!! but peace, peace, parser,
peace! thou talk'st of nothing. :-)

I am afraid I shall miss the following harrowing explanation (not by
you, I know you meant it with a dash of humour), full of rage and fury
and signifying nothing, about the outermost importance of the type and
of the strict validation and of how much of an incredible hopeless
crooked disgusting moron and despicable blackguard I am to vilify such
an important momentuous pivotal thing like the type attribute in the
script tag.... :)

ciao
Alberto
http://www.unitedscripters.com/