On quarta-feira, 22 de fevereiro de 2012 17.11.17, [email protected] wrote:
> Hi,
> 
> this is the first mail where I'd like to go through the remaining features
> for Qt 5.0.
> 
> I know that this bug is blocked by not having PCRE in 3rdparty/. But how
> is the status apart from this? Thiago, simply tell me if you feel
> comfortable with the code and I'll do final review and approval. If it
> doesn't break BC and is standalone from other code in qtcore, it can go
> into master, otherwise I'd prefer it to go into api_changes.

I'm comfortable with the code as-is. Peppe has already submitted a couple of 
changes on top, which fix issues he's already found. Arguably, they could be 
squashed together, but I don't think that matters.

The one remaining issue is the use of mutex-protected data. But I think we've 
got the proper fix in already. We'll only know more once people start using it.

> There's another related issue to this bug: What do we do with the old
> QRegExp? I've gripped through our code and removing it is a larger
> surgical operation.

Indeed. I really have no clue how hard this would be.

The uses of QRegExp in qtbase and my proposals would be:

 - qmake: lots of use, keep it by copying qregexp.cpp into qmake
 - rcc: one single use, very easy to rewrite without regexes
 - uic: #includes are unnecessary; remove immediately
 - QtCore API:
        * QString non-const QRegExp&: use templates to support QRegExp in 
inline 
          code (find a way), or simply stop supporting this
        * QMetaType & QVariant: let RegExp point to the new class
        * everywhere else (including QStringList): replace with the new class
 - QtCore internal uses: use the new class or rewrite (if possible, I 
   recommend a non-regex globbing in QDir and QDirIterator). If the class is 
   used in bootstrap, then the function in question must be opted out or the 
   code rewritten, like qdatetime.cpp and this comment in qxmlutils.cpp:
    /* Right, we here have a dependency on QRegExp. Writing a manual parser to
     * replace that regexp is probably a 70 lines so I prioritize this to when
     * the dependency is considered alarming, or when the rest of the bugs
     * are fixed. */
 - QtXml: used in bootstrap, so must rewrite without regex. Or refactor rcc to 
   use QXmlStreamReader instead of QDom, then remove 
 - QtGui API:
        * QTextDocument: replace with the new class
        * QRegExpValidator: move alongside QRegExp, but add a new class to QtGui
 - QtNetwork API:
        * QSslSocket (globbing functions for certificates): replace with new 
enums
 - QtScript API: replace with new class (same goes for QJSEngine)
        Maybe since QtScript is done, we leave it as is. But QJSEngine should 
use 
        the new class.
 - document gallery: I don't know

Everywhere else it's either internal use or doesn't have QRegExp in the API.

Then we move QRegExp and QRegExpValidator to a new library, like QtConcurrent. 
We also modify QRegExp to add:

        QRegExp(const QRegularExpression &); // implicit
        operator QRegularExpression() const;

> So I'd propose that we now bite the bullet and leave it in QtCore. Let's
> simply mark it as deprecated since 5.0, and live with the additional 100k
> in QtCore.

That's another option, unless someone manages to pull off what I said above.

I'd still recommend we clean up the API more or less along the lines of what I 
said above.

-- 
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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to