Compiling the pattern is the slower operation. The matching is not that slow. Since the Pattern is static it is compiled just once. Having semi-working solution like current EmailAddressValidator is not an option. If Rfc** one proves to be slow then we should better find a way to optimize it or find another RFC compliant solution.
On Sat, Jul 21, 2012 at 9:29 PM, Burton, Tom F (DOR) <[email protected]> wrote: > What about speed isn't regular expression matching slow? And wouldn't > matching on a gigantic regular excpression like RFCCompliantValidator take a > while? > > Tom Burton > > Sent from my HTC > > ----- Reply message ----- > From: "Martijn Dashorst" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [vote] deprecate/remove EmailAddressValidator and move > RfcCompliantEmailAddressValidator to core > Date: Fri, Jul 20, 2012 4:50 am > > > > EmailAddressValidator is broken. For example, it doesn't validate > "Martijn Dashorst <[email protected]>" properly, which is > standards compliant. Rfc validator does work. The only reason why RFC > validator was not admitted to core, was its memory consumption due to > the regular expression. But since RFC is now singleton, I severely > doubt that is still an issue. > > [ ] Copy RfcCompliantEmailAddressValidator over EmailAddressValidator, > deprecate RfcCompliantEmailAddressValidator > [ ] Deprecate EmailAddressValidator, move > RfcCompliantEmailAddressValidator to core, favor RFC in EmailTextField > [ ] Keep it as currently implemented > > Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
