RegExp FAQENTRY

[Dr John Stockton]

ISTM that RegExps deserve a FAQ entry, with links to more detailed
sources.

An important question, probably not treated by many otherwise worthwhile
sources, must be on feature detection of the newer RegExp facilities -
for example, greedy/non-greedy.

The answer may be that it is not possible to do so in a safe manner;
that one can do no better than something like

document.write("Testing non-greedy :- ")
X = /<trialRegExp>/.test(string)
document.write("survived.")

That is, nevertheless, a useful answer; if it is right, it prevents the
naive seeking anything better, and if it is wrong someone will soon say
so.

Where a page requires an advanced RegExp facility, it is best to have a
controlled failure at a well-chosen point.

Putting something in the posted FAQ will provide an opportunity for
adding a reference to the Notes; and, without such a reference, their
value is much reduced.

 

[Richard Cornford]

ISTM that RegExps deserve a FAQ entry, with links to more
detailed sources.

An important question, probably not treated by many otherwise
worthwhile sources, must be on feature detection of the newer
RegExp facilities - for example, greedy/non-greedy.

The answer may be that it is not possible to do so in a safe
manner; that one can do no better than something like

document.write("Testing non-greedy :- ")
X = /<trialRegExp>/.test(string)
document.write("survived.")

That is, nevertheless, a useful answer; if it is right, it
prevents the naive seeking anything better, and if it is
wrong someone will soon say so.

Where a page requires an advanced RegExp facility, it is
best to have a controlled failure at a well-chosen point.

<snip>

A little provisional testing suggest that the regular expression
features (such as non-greedy) may not be that difficult to feature
detect. Trying some reg ex syntaxes that should be problematic on older
browsers did not result in any errors, just different results. Which
means that using String.replace (at least) on a test string it should be
reasonable to assume that the regular expression implementation supports
the required feature if the resulting string equal the expected result.

The following examples list the operation used and the resulting strings
on various browsers, including a couple of dinosaurs.

"a".replace(/a??/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
X X a Xa Xa Xa


"aaaa".replace(/(a){2,4}?/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
X X aaaa Xaa Xaa Xaa


"aaaa".replace(/(a){2,}?/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
X X aaaa Xaa Xaa Xaa


"aaaab".replace(/a(?=b)/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
aaaab aaaab aaaab aaaXb aaaXb aaaXb


"aaaab".replace(/a(?:b)/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
aaaab aaaab aaaab aaaX aaaX aaaX


"aaaab".replace(/a(?!b)/, 'X')

HotJava3 Net 4 Opera 6 Opera 7 Mozilla 1.3 IE 6
aaaab aaaab aaaab Xaaab Xaaab Xaaab


Obviously I don't know for sure that these tests will not produce errors
on any browsers. It would certainly be worth seeing what IE 4 makes of
them.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Richard Cornford
<[email protected]> posted at Sat, 6 Mar 2004 01:55:44 :-

Obviously I don't know for sure that these tests will not produce errors
on any browsers. It would certainly be worth seeing what IE 4 makes of
them.

All of them give me an "Internet Explorer Script Error" window,
"unexpected quantifier". Answering Yes, the return value appears to be
undefined, i.e. as var U gives.

So the tests can be used in IE4, with no more annoyance than a failure
in actual use would cause.

I take it that the last 3 browsers give the "proper" result.

ISTM that if browsers such as the first three are in use, then feature
testing before feature use is essential, otherwise the user is at risk
of being given a miscalculated result.

 

[Richard Cornford]

Richard Cornford posted at Sat, 6 Mar 2004 01:55:44 :-

All of them give me an "Internet Explorer Script Error" window,
"unexpected quantifier". Answering Yes, the return value appears to
be undefined, i.e. as var U gives.

It is a pity that IE 4 generates the error report. I was actually
expecting the other three to generate error reports when they
encountered the unexpected qualifiers in the regular expressions (or
just stop executing scripts in the case of HotJava) and was pleasantly
surprised when they just created "incorrectly" functioning RegExp
objects.

Even in the case of IE 4's error report the script can carry on under
control if the use clicks yes and a subsequent string comparison should
be able to tip the code off that it must not attempt to use the more
advanced regular expressions again. The worst case is no worse than
attempting to use the newer features untested and testing avoids placing
a reliance on the results of an "incorrectly" functioning RegExp.

So the tests can be used in IE4, with no more annoyance than
a failure in actual use would cause.

Yes, and with Netscape 4 and Opera 6 still in fairly common use it has
got to be worth it.

I take it that the last 3 browsers give the "proper" result.

They are results consistent with my understanding of what the various
formulations of the RegExp used should have done (by ECMA 262 ed 3 &
Perl 5 specs).

ISTM that if browsers such as the first three are in use, then feature
testing before feature use is essential, otherwise the user is at risk
of being given a miscalculated result.

It is consistent with the feature detecting philosophy to verify the
feature (and in this case its functionality) before placing any reliance
on it. It would be better if there was a way to test without risking an
error. Ideally a RegExp formulation that was syntactically valid under
all levels of implementation but behaved differently. If there is such a
formulation I am not sufficiently familiar with regular expressions to
spot it.

Richard.

 

[rh]

JRS: In article <[email protected]>, seen in
Richard Cornford
<[email protected]> posted at Sat, 6 Mar 2004 01:55:44 :-




All of them give me an "Internet Explorer Script Error" window,
"unexpected quantifier". Answering Yes, the return value appears to be
undefined, i.e. as var U gives.

So the tests can be used in IE4, with no more annoyance than a failure
in actual use would cause.

As I recall, IE4 supports window.onerror, so for this case you may
want to consider:

var onerrorSave = window.onerror;
window.onerror = catchError;
testRe = new RegExp("a??");
window.onerror = onerrorSave;

where the function catchError can provide graceful failure, or
invocation of alternative execution.

Assignment of window.onerror in browsers that don't support it should
be harmless.

..\rh

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen

As I recall, IE4 supports window.onerror, so for this case you may
want to consider:

var onerrorSave = window.onerror;
window.onerror = catchError;
testRe = new RegExp("a??");
window.onerror = onerrorSave;

where the function catchError can provide graceful failure, or
invocation of alternative execution.

Assignment of window.onerror in browsers that don't support it should
be harmless.

The following alerts "Caught" and then "2 Before" :

<script>

function catchError() { alert('Caught') ; return true }

testRe = "Before"
var onerrorSave = window.onerror;
window.onerror = catchError;
testRe = new RegExp("a??");
window.onerror = onerrorSave;
alert("1 " + testRe) // not shown

</script>

<script>

alert("2 " + testRe)

</script>


Thus the offending statement has no effect, and the rest of the script
section is abandoned. For IE4, therefore, the test is satisfactory; it
needs to be demonstrated to be harmless elsewhere.

Netscape's web-site showed onError (big E), which does not serve for
that.