On Wed, Oct 12, 2011 at 5:17 PM, Pau Garcia i Quiles <[email protected]> wrote: >> this is not just about missing functionality: the current QRegExp is >> broken[1], and renaming it won't fix that, nor will it discourage >> people from using it. >> > > The API can be fixed
that requires a maintainer, which it does not have >> Apart from the purist's line of thought, it's also very, very slow in >> a number of common cases (and really, really slow in some >> not-so-common ones). > > There is nothing wrong with that. I disagree. Or do you really want to deliberately handicap applications? > You want advanced regexp features and a very performant regexp engine? > You'll need to depend on some other module. This is perfectly fine for GUI > applications. In the end, anyone who does GUI will use the new regexp > engine; anyone who does not do GUI will either use QSimpleRegExp or find an > alternative (PCRE, RE2, etc) Nothing stops the adoption of one of those new engines as the backend for the new regexp-for-Qt, and in fact, I'd encourage that over keeping the existing implementation, even if that did mean a utf16 conversion - it'd probably still be faster for most cases (benchmarking needed, obviously), and nothing stops someone adding utf16 support to that engine, or worst case [in theory] precludes changing that engine later, should one more suitable pop up. don't get me wrong here: I'm as sceptical as you are about requiring V8 or something else for regex, I have written a lot of headless code using Qt, and I'm not really getting happy warm thoughts about that, even without actually doing firm measurement on what the impact would be. But I don't think the status quo is a good one - perhaps because I've actually had to step in and rip out QRegExp in places where performance was an issue in order to attain responsive applications, 60fps drawing, etc thanks, Robin _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
