6 ms·
A neat idea, but I'm against hiding the underlying regular expressions from a user. They're such a powerful tool, anyone using them for matching or extraction s
by injekt 14y ago
A neat idea, but I'm against hiding the underlying regular expressions from a user. They're such a powerful tool, anyone using them for matching or extraction should read up on them. That said, for simple use this is cool and probably something that would appeal to beginners.
A 0 config 0 feature simplified version in Ruby https://gist.github.com/3832504 https://gist.github.com/3832504
- charliesome 14y agoIf you replace the `\S+` with a non-greedy wildcard (`.*?`), you gain a lot more flexibility: http://eval.in/1316 http://eval.in/1316
- jdwhit2 14y agoThis examples looks like it covers a large number of cases: extractValues('John Doe <john@example.com> (http://example.com)', '{name} <{email}> ({url})') >> {'name': 'John Doe', 'email': 'john@example.com', 'url': 'http://example.com' } What kinds of problems would you run into vs using regex? My thoughts were that you lose some control of your matches.
- keeperofdakeys 14y agoYou lose the ability to write them quickly, which considering I mainly use them for code editing or one-off uses, is quite important. The thing about regular expressions is they aren't suited to general programming in their normal form (since they are hard to read, and slow), and the quoted example is better described as a general parser, and could be implemented much better directly then abstracting through regular expressions.
- VMG 14y agoWe hide and abstract things in programming all the time. For example, the proper (RFC-compliant) regex for an email is very complicated and often implemented the wrong way. As somebody who has written a lot of regexes, I'd rather uses this library which has the correct abstraction than google the regex for http-urls for the 512th time.
- judofyr 14y agoThis library doesn't help you here though. It doesn't bring you any abstractions on top of regexes (e.g. parsing URLs/emails). This is merely a different syntax for matching parts of a string.
- keeperofdakeys 14y agoI hope no one is seriously suggesting that regular expressions should be used in programs, such as email address verification and http parsing. As well as being incredibly slow, they are hard to read, and inferior to application-specific parsers (for example, sometimes non-RFC-compliant emails are actually valid, and dealing with whitespace in html is a nightmare). For the interactive case, the ability for them to be written quickly is what makes them so helpful, and an abstraction library could take away this advantage.
- randallsquared 14y agoI hope no one is seriously suggesting that regular expressions should be used in programs, such as email address verification and http parsing. I think the comma changes the meaning of your sentence from what you intended. It was refreshing, though! To be clear, with the comma, this reads essentially as "Don't use regexes in programs. Some examples of programs are ...".
- rjbond3rd 14y agoI'm not exactly disagreeing but just curious: 1. How can a non-RFC-compliant email be valid? 2. What about compiled regexes, performance-wise? 3. Sometimes a regex is faster than the overhead of a parser, so wouldn't the choice be dependent on context? In other words, regexes are not always slower, true? 4. Wouldn't some abstraction libraries utilize regexes under the hood? Would that be wrong in your view? P.S. Some languages allow the option for very readable regexes, e.g. separate each component on its own line, with a comment.
- Domenic_S 14y ago> How can a non-RFC-compliant email be valid? 甲斐@黒川.日本 is a non-RFC 5322-compliant, but still valid, email address. Unless you're implying that "valid" === RFC 5322-compliant, in which case the example isn't valid ;) The best way to validate an email address: send an email to that email address containing a confirmation link. Simple, easy.