3 ms·

I usually use look ahead negation to make tests that string doesn't match regex.

by prohor 11y ago

lolc 11y ago
What do you mean by "usually"? What situation calls for this? I wonder why people seem to consider this a worthy addition where in my view it only serves to complicate the implementation. From what I see these additions become useful long past the point where using a regex was sensible in the first place.
- solipsism 11y ago
  I've used lookbehind assertions (and negative lookbehind assertions) many times. Most recently I used them to do some complex find/replaceing across a pretty large codebase. My editor supports regex, and I'm glad it does because it made the job easy. From what I see these additions become useful long past the point where using a regex was sensible in the first place. Regex stops being a sensible solution when your pattern starts getting overly complex. The fact that you use one of these features doesn't imply your pattern is overly complex. These are not complex features, they're easy to use, and often extremely useful. For example when straightforward find/replace doesn't cut it. What would you suggest, I take 10 minutes to write a Python script for what took me about 15 seconds in my editor's Find/Replace box?
  - lolc 11y ago
    I see how this can be useful for ad-hoc replacements. To clarify, I'm not asking about the usefulness of the feature in general but why it makes sense to add this to JS.
    - paulddraper 11y ago
      Because JS is a general purpose language?
- mioelnir 11y ago
  I once argued that it `could not be so hard to write a regexp that validates Debian package versions`. Ohboy. Let's just say that in the end it became a point of pride to come up with something. Debian package version numbers have leading and trailing optional parts and if they are specified, then the characters used as separator of these parts are allowed as part of the version number. The resulting regexp ended up being essentially four different regexp expressions with four leading conditions utilizing look-ahead and look-behind matching to select which inner regexp to use. It was sufficiently beyond actually regular, even if supported by modern RE tools. And this is a common pattern in my experience. If you frequently need look-ahead or look-behind, you are often past something you should reasonably disassemble using regexp and should instead start defining a grammar and parse the input stream against it.
  - paulddraper 11y ago
    The Debian version format was not made to be easy. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version https://www.debian.org/doc/debian-policy/ch-controlfields.ht... But in any case, this works. ^(\d+:|(?!.*:))(?!.*-[^-]*:[^-]*$)\d(-?[A-Za-z0-9.+:~])*$ Actually, I think I variable-width lookbehind might be handy here to check the hyphens, but I don't have Chrome 49, so I'll forgo it.
    - mioelnir 11y ago
      I'd contend that it was "made" at all. When I first looked at the relevant section of the policy manual, my takeaway was that they had a script that iteratively removed the leading and trailing optional fields, making use of the separators safe only if the fields were there so the script did not misfire. They then took the runtime behavior of that existing script and called it the standard.

I usually use look ahead negation to make tests that string doesn't match regex.

by prohor 11y ago

I usually use look ahead negation to make tests that string doesn't match regex.

lolc 11y ago

What do you mean by "usually"? What situation calls for this? I wonder why people seem to consider this a worthy addition where in my view it only serves to complicate the implementation. From what I see these additions become useful long past the point where using a regex was sensible in the first place.

solipsism 11y ago
I've used lookbehind assertions (and negative lookbehind assertions) many times. Most recently I used them to do some complex find/replaceing across a pretty large codebase. My editor supports regex, and I'm glad it does because it made the job easy. From what I see these additions become useful long past the point where using a regex was sensible in the first place. Regex stops being a sensible solution when your pattern starts getting overly complex. The fact that you use one of these features doesn't imply your pattern is overly complex. These are not complex features, they're easy to use, and often extremely useful. For example when straightforward find/replace doesn't cut it. What would you suggest, I take 10 minutes to write a Python script for what took me about 15 seconds in my editor's Find/Replace box?
- lolc 11y ago
  I see how this can be useful for ad-hoc replacements. To clarify, I'm not asking about the usefulness of the feature in general but why it makes sense to add this to JS.
  - paulddraper 11y ago
    Because JS is a general purpose language?
mioelnir 11y ago
I once argued that it `could not be so hard to write a regexp that validates Debian package versions`. Ohboy. Let's just say that in the end it became a point of pride to come up with something. Debian package version numbers have leading and trailing optional parts and if they are specified, then the characters used as separator of these parts are allowed as part of the version number. The resulting regexp ended up being essentially four different regexp expressions with four leading conditions utilizing look-ahead and look-behind matching to select which inner regexp to use. It was sufficiently beyond actually regular, even if supported by modern RE tools. And this is a common pattern in my experience. If you frequently need look-ahead or look-behind, you are often past something you should reasonably disassemble using regexp and should instead start defining a grammar and parse the input stream against it.
- paulddraper 11y ago
  The Debian version format was not made to be easy. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version https://www.debian.org/doc/debian-policy/ch-controlfields.ht... But in any case, this works. ^(\d+:|(?!.*:))(?!.*-[^-]*:[^-]*$)\d(-?[A-Za-z0-9.+:~])*$ Actually, I think I variable-width lookbehind might be handy here to check the hyphens, but I don't have Chrome 49, so I'll forgo it.
  - mioelnir 11y ago
    I'd contend that it was "made" at all. When I first looked at the relevant section of the policy manual, my takeaway was that they had a script that iteratively removed the leading and trailing optional fields, making use of the separators safe only if the fields were there so the script did not misfire. They then took the runtime behavior of that existing script and called it the standard.