>function* match(regex, haystack){
> var {source, ignoreCase} = regex;
> var newRegex = new RegExp(source, ignoreCase ? 'gi' : 'g');
> var m = null;
> while (m = newRegex.exec(haystack)) {
> yield m;
> }
>}
this code is not best in that case:
var regex = /\d+/;
var first = match(regex, "1
you can also use this code ... like today, with every browser, and right
away ...
```javascript
function match(regex, haystack){
var result = [], g = regex.global, match;
do { match = regex.exec(haystack) }
while(match && result.push(match) && g);
if (!g) regex.lastIndex = 0;
return re
(Sorry for the delay of response, I am currently in a remote area.)
> Le 6 juil. 2014 à 20:15, André Bargull a écrit :
>
>
>> Moreover, the Completion record (either normal or abrupt) returned
>> from [[Call]] will hold an additional [[thisValue]] field,
>> which, unless otherwise specified:
>>
(Sorry for the delay of response, I am currently in a remote area.)
Le 7 juil. 2014 à 19:02, Kevin Smith a écrit :
>>
>> 1. During phase /* 1 */, the this-binding is uninitialised; trying to access
>> it through an explicit `this` keyword will throw a ReferenceError.
>
> This seems overly
(Note that this topic is on the agenda for this month's TC39 meeting)
(Also, note that as far as I can tell, the disagreement is only about the early
errors described below. The use of a separate parameter scope that limits what
closures in parameter expressions can capture has been agreed upon
Here are some relevant discussions from past meetings:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#proposal-part-2
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-18.md#510-function-parameter-scoping-and-instantiation
https://github.com/rwaldron/tc3
You could wrap it in an iterator :-)
http://www.es6fiddle.net/hxoczoqg/
```javascript
function* match(regex, haystack){
var {source, ignoreCase} = regex;
var newRegex = new RegExp(source, ignoreCase ? 'gi' : 'g');
var m = null;
while (m = newRegex.exec(haystack)) {
yield m;
}
}
var i
Yes, the /g flag is confusing, because the regular expression kind of turns
into an iterator. I’d much prefer an actual iterator-based API that doesn’t
mutate the regular expression.
On Jul 16, 2014, at 9:26 , Alex Vincent wrote:
> r = /\u0020+$/g; p = r.exec(" "); q = r.exec(" "); JSON.stri
expected by specs ... try this
r = /\u0020+$/g; p = r.exec(" "); r.lastIndex = 0; q = r.exec(" ");
alert(JSON.stringify([p, q]))
and you are good to go
... without resetting lastIndex, you can also use " ".replace(r,
'whatever') and it's going to work every time.
Have a look at these slides
r = /\u0020+$/g; p = r.exec(" "); q = r.exec(" "); JSON.stringify([p, q])
// "[[\" \"],null]"
Why does calling exec the second time generate null? When I try the
regular expression without the /g flag, I get:
// "[[\" \"],[\" \"]]"
--
"The first step in confirming there is a bug in someo
10 matches
Mail list logo
