On Tuesday, 25 de October de 2011 23.33.04, Frans Klaver wrote: > > 1) document very well what is true and what isn't > > Restricting the use to e.g. English only, would not be really useful when > parsing (localized) user input, although I don't think this would happen a > lot. I only know of a few cases where an end-user is expected to > explicitly type yes or no into an input field, and those are command line > tools. Wouldn't that be pretty much the only use case? > > I might have overlooked things. It's getting late anyway.
I agree with your argument, I just don't think it's applicable. QString is not
localised and has never promised to be. QString::number generates C-locale
numbers and toInt/toDouble parse C-locale; QDate::toString generates C-locale
dates (or should), etc. If you want localised information, you should use
QLocale.
> > 2) make sure all three classes work the same way. If not, change them so
> > that they all have toBool() const and they all operate equally.
> >
> > 3) add unit tests
> >
> > 4) ensure that QVariant::toBool calls into QString::toBool and
> > QByteArray::toBool, as applicable. Note pending the commits by Jędrzej
> > that are refactoring the QVariant internals.
>
> If QString::toBool() is added, would there also be a need for something
> like static QString::boolean(bool value, char format = 't')?
It's much easier to use the ternary operator and just select which option you
want to use.
--
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
