(belated followup) > I think a lot of people (myself included) use a similar mental model, > although it doesn't quite match the implementation details. But even > according to this model, avoiding /y wouldn't keep ES regex flags pure as > mere pattern attributes since ES already crossed that bridge with /g (and no > one complains about it).
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. Can we summarize this discussion on a wiki page somewhere? I think it more or less came to a conclusion : ) >> Though as mentioned, gracefully upgrading with ES3-5 is an issue, so I >> could only think of .exec() and .execLeft() for a left-anchored match. > > Unlike execLeft, /y or \G would be useful not only with regex.exec/test, but > also with string.match/replace/split; and all this in > backwards-compatible fashion (unlike adding new arguments or methods). The > name execLeft might also be misleading since I imagine it would cause global > regexes to be lastIndex-anchored rather than left-anchored. Yeah true. /y works for me. I wasn't really proposing execLeft anymore, just considering its advantages. > Regarding the pos and endPos arguments > you've proposed: > > - An endPos argument might be useful with the replace and match methods when > using global regexes, but it would probably have limited use-cases with exec > and makes no sense with execLeft (assuming endPos is the last position where > a match can start). If, rather, it's the position at or before where the > last match must end, it would offer nothing more than a *possible* slight > performance improvement vs. regex.execLeft(str.slice(0, endPos)). Searching > a sliced copy of the string would actually have the potential to perform > *better* if it prevents having to complete a slow match attempt that goes > beyond endPos before being discarded upon completion. The pos and endpos arguments would be synonymous with slicing the string, but more efficient. In fact the Python docs say explicitly that they're equivalent. I think so far everyone agrees with the 'pos' optimization. I'm not going to push for endpos but I thought I'd mention it. > - A pos argument (which you mentioned elsewhere) is unnecessary and > confusing for test/exec/execLeft since the lastIndex property already > provides the same functionality (albeit with the requirement that it's used > with a global regex). I wish exec, test, replace, and match all offered a > pos argument and that the lastIndex property didn't exist, but that ship has > sailed. Well, the proposal is that pos, if passed, overrides lastIndex. Is there something wrong with that? The point is that the same RegExp() instance can be used in concurrent contexts without the stomping on lastIndex. > I too like Python's regex methods, but I don't think that what Python does > well here can easily be dropped on top of ES5. Well I'm only proposing a very small subset. And I think JS has already admitted its influence by Python. Putting \G in because Perl uses it is a bad reason, since following Perl to Perl 5 regexps would be an atrocity : ) Unless someone is seriously arguing for \G, I think it should be ruled out. As you mentioned, it's more complicated to implement since \G doesn't have to be at the beginning. thanks, Andy _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
