On Wednesday, 23 de November de 2011 15:48:41 Robin Burchell wrote: > 2011/11/23 Thiago Macieira <[email protected]>: > > We don't even have to mark this one deprecated. If the new engine's API is > > compatible, it could be used for both. > > well.... doesn't that depend on how complete you want SC to be? > QRegExp uses different syntax than pretty much every other RE engine, > definitely different from PCRE, and supports different features. So if > people have hardcoded regular expressions, they may function > differently, or not at all.
It will not be source-compatible because the class name will be different.
That's not what I was advocating.
I was advocating having a similar API (what Matthias called "static
polymorphism" in his article on QQ13). That is, having an
int indexIn(const QString &string) const;
method. It brings familiarity: people who used this method in QRegExp will
know what to expect.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
