so, where’s the email address regex? that’s where this lives or dies. there is no reason to use this for extremely simple happy-path regexes.
i’m having a tough time understanding who this is for. a beginner might think this is great, but they’re shooting themselves in the foot by adding an additional layer of abstraction rather than reading something to learn the basics.
I am of the opinion that regex for email address is a bad idea. The only two things that you need to check an email address are:
Does the address contain an @ symbol?
Is there a dot to the right of the @ symbol?
Then just try to deliver to it, and let the MTA do the rest.
Email addresses can be complicated, and there's plenty of valid addresses that can be excluded by attempts at regex validation.
I agree. In fact, the only check is if it contains the @ symbol, since "com" and other TLDs/gTLDs can have MX records, it is possible to have email@com. Not that we'd ever see it in practice though.
@Zikeji It's possible for TLDs to have A records, and for a while there were a few that did. But ICANN forbids top level A records, and I wouldn't be surprised if they forbid top level MX records as well.
Anyway, you would literally enter the address as "email@com." including the trailing dot, which represents the DNS root that contains all the TLDs. You can also think of the trailing dot as an indicator of a FQDN (instead of a hostname within your local search domain).
i said “email” but what i meant was “show me a complicated example”. i don’t disagree with anything you said.
If it can do that, i might just use it. It'll make code a whole lot cleaner to read.
I disagree. Anyone familiar with regex can debug these statements post conversion. Anyone not familiar with regex is going to have to learn something in order to debug the statement. I'd rather learn something that's expressive and easy to visually parse.
regex syntax is a vestige of the old "as few bytes as possible" era where every character of code had to be written personally. It's an obsolete way of thinking for the vast majority of programming.
so, where’s the email address regex? that’s where this lives or dies. there is no reason to use this for extremely simple happy-path regexes.
i’m having a tough time understanding who this is for. a beginner might think this is great, but they’re shooting themselves in the foot by adding an additional layer of abstraction rather than reading something to learn the basics.
I am of the opinion that regex for email address is a bad idea. The only two things that you need to check an email address are:
Does the address contain an @ symbol?
Is there a dot to the right of the @ symbol?
Then just try to deliver to it, and let the MTA do the rest.
Email addresses can be complicated, and there's plenty of valid addresses that can be excluded by attempts at regex validation.
@custom_situation @yoavlavi
I agree. In fact, the only check is if it contains the @ symbol, since "com" and other TLDs/gTLDs can have MX records, it is possible to have
email@com. Not that we'd ever see it in practice though.@Zikeji It's possible for TLDs to have A records, and for a while there were a few that did. But ICANN forbids top level A records, and I wouldn't be surprised if they forbid top level MX records as well.
Anyway, you would literally enter the address as "email@com." including the trailing dot, which represents the DNS root that contains all the TLDs. You can also think of the trailing dot as an indicator of a FQDN (instead of a hostname within your local search domain).
i said “email” but what i meant was “show me a complicated example”. i don’t disagree with anything you said.
If it can do that, i might just use it. It'll make code a whole lot cleaner to read.
I disagree. Anyone familiar with regex can debug these statements post conversion. Anyone not familiar with regex is going to have to learn something in order to debug the statement. I'd rather learn something that's expressive and easy to visually parse.
regex syntax is a vestige of the old "as few bytes as possible" era where every character of code had to be written personally. It's an obsolete way of thinking for the vast majority of programming.