On Aug 29, 2013, at 1:13 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Axel Rauschmayer wrote:
>> * /g flag must be set
>> * lastIndex must be 0
>> * can’t inline the regex, because it is needed as a pseudo-iterator (more of an anti-pattern, anyway, but still)
>> * side effects via lastIndex may be a problem
> 
> Anything we do of the execAll/execIter kind had better be immune to the awful Perl4-infused "mutable lastIndex state but only if global" kind. Compositionality required.
> 
> The design decision to face is what to do when a global regexp is used. Throw, or ignore its lastIndex?

I would favor ignoring lastIndex rather than throwing, but to be sure can you clarify what you mean by global regexp?

If we're talking /.../g, then my feeling is that the /g should be ignored -- if you're wanting a regexp iterator for a string (or whatever) I would think that the API would imply that all regexps were intended to be "global".

If we're talking about multiple concurrent iterators with the same regexp/string then it should definitely be ignored :D

Erm.

I'm not sure if that's coherent, but the TLDR is that I favor ignoring all the old side state warts (i would not have iterators update the magic $ properties, etc)

--Oliver

> 
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

On Aug 29, 2013, at 1:13 AM, Brendan Eich <brendan at mozilla.com> wrote:

> The design decision to face is what to do when a global regexp is used. Throw, or ignore its lastIndex?

I would favor ignoring lastIndex rather than throwing, but to be sure can you clarify what you mean by global regexp?

If we're talking /.../g, then my feeling is that the /g should be ignored -- if you're wanting a regexp iterator for a string (or whatever) I would think that the API would imply that all regexps were intended to be "global".

If we're talking about multiple concurrent iterators with the same regexp/string then it should definitely be ignored :D

Erm.

I'm not sure if that's coherent, but the TLDR is that I favor ignoring all the old side state warts (i would not have iterators update the magic $ properties, etc)