4 ms·
This looks like a cool project, but I don't know how I feel about the non-primitive type loaders. Date strings, email addresses, urls, colors, and lat-long are
by NoahTheDuke 8y ago
This looks like a cool project, but I don't know how I feel about the non-primitive type loaders. Date strings, email addresses, urls, colors, and lat-long are hard problems, and trying to handle them in the spec is a misstep. Leave the complex loaders out, strive to handle perfectly just the core list of primitives, and let devs write their own email or url parsers. (Who is asking for lat-long parsing?)
(Seriously, the email parser doesn't match most of the Examples [0] on the Wikipedia page about email validation. Don't use regex to validate unless you're gonna write `/.* @.*/`.)
[0]: https://en.wikipedia.org/wiki/Email_address#Examples https://en.wikipedia.org/wiki/Email_address#Examples
- simonrepp 8y agoI fully agree with your assessment - eno allows arbitrary types, therefore if and to what extent non-primitive type loaders should be included as core functionality needs to be thoroughly considered and negotiated soon. I included non-primitive loaders (also the exotic lat/lng ;)) to (a) show that this is a possibility and (b) get hands-on insight how well this works in real world usage. (in short: I love it so far, but I'd love to hear other experiences!) It took months to get the whole ecosystem jump-started as a one man show, so that's why some loaders are ... pragmatically coded, you're of course right on that, although admittedly I had no idea the email spec was that complex, thanks for making me aware. ;)