[Development] Converting types in Qt

Bubke Marco Marco.Bubke at digia.com
Wed Jul 16 15:26:09 CEST 2014


Hi

In the qml designer we are using comparisons of variants quite extensive and run in smaller problems like wrong conversions. E.g. color is broken because the alpha value is not used in the comparison. We would like to extent existing comparisons too because we get the variants from different sources, so the "value" is "equal" but because the conversion is not working it is not the "same". Thomas Hartmann was running in more problems like that and if he is back in two weeks you should ask him.

Best, Marco
________________________________________
From: development-bounces+marco.bubke=digia.com at qt-project.org [development-bounces+marco.bubke=digia.com at qt-project.org] on behalf of Jędrzej Nowacki [jedrzej.nowacki at digia.com]
Sent: Tuesday, July 15, 2014 8:55 AM
To: development at qt-project.org
Subject: [Development] Converting types in Qt

Hi,

    I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, "int" to "long", but also for more complex
ones like "QByteArray" to "QString" or "CustomType" to "OtherCustomType". Type
conversion in Qt happens mostly without user interaction, for example in
QObject introspection or in QML, but it also can be used through public API:
  - QVariant::convert -> converts wrapped value to target type
  - QVariant::canConvert -> fast check if it may be possible to convert
wrapped type to a given target, which is, in my opinion, pretty useless,
unless the real conversion is really heavy
  - QMetaType::registerConverter -> allows to register a custom converter
function for a user defined type
  - QMetaType::convert -> perform conversion between two types

    I would like to agree on some rules, regarding conversions, as the current
approach is chaotic:

  1. Are we allowed to add new conversions?

     The question is tricky because adding a new conversion is a behavior
change, as this code:
     if (variant.canConvert(QMetaType::int)) ...
     may work differently. If we add custom types into the mix, everything is
even more complex.

     1.1 Patch release or minor release only?

         I would say that new conversions may appear only in minor releases,
obvious fixes to existing conversions may appear in patch releases, where by
obvious I mean crash fixes and cases in which the returned value is definitely
bogus.

     1.2 Should conversion be perfect or based on a best effort?

         Some of the conversion API returns a "bool" value which is a status
of conversion. What should it return if a conversion is not perfect, for
example "int(-1) -> uint" or "QVariantList{string, int, myobject} ->
QStringList", should such a case be detected? How do we define the perfect
conversion? Sometimes only ideal, data lossless, conversions should be
allowed, for example QtTestLib is quite strict about it and it allows only
safe conversions. So, for example, "int -> long" but not "uint -> int", but I
guess for normal use cases such strictness is not necessary.
         I think we should base conversions on the best effort and set the
status to false only if a conversion failed completely, that is mainly if a
conversion is unknown or if underlying implementation detected a failure, like
"QByteArray -> float" which uses QByteArray::toFloat(bool *ok)

     1.3 Should we try to support a user's type conversions out of the box?

         Currently a user needs to manually register a conversion function so
Qt can know it and use it. For certain types we can do much better, because we
can automatically convert some types. For example:
         QVector<char> -> QLinkedList<int>
         QList<Foo> -> QVector<Foo>
         QPointer<Foo> -> QObject*
         QPointer<Foo> -> void*
         QSharedDataPointer<Foo> -> bool
         MyQObject* -> QPointer<MyQObject>
         Currently we are not doing it for one reason which is behavior
compatibility. What if a user already defined a conversion that we want to add?
It could happen because the conversion was not available in a previous Qt
version. The problem is that the new conversion function may behave in a
different way, especially in edge cases and because of the lack of perfection
mentioned in 1.2. We need to pick only one function. That could be the Qt
version, but then we risk that an existing code will not work anymore. Are we
willing to accept that?
         I believe that we should document the problem, and allow the
conversions.

     1.4 Should a user be able to add Qt types conversion on his own?

         Some conversions are missing, some we consider as not safe. A user,
assuming that he knows what he is doing, could register a conversion; for
example, "QString -> QChar", how bad is it? Currently, such usage is blocked,
because we are afraid that in the future we may add a conversion that
overrides it.
         In my opinion it is not needed; it is a corner case, because we a)
should have the conversion and then it will appear in a future version b) the
conversion is invalid, and it is a sign of a user's broken code.


  2. Can we modify an existing conversion?

     All modification changes behavior. Of course we assume that changes are
sensible, but still it may break existing code.

     2.1 Can we improve a conversion?

         For example, "QStringList -> QString" is very tempting, as it works
only if the list is of size 1. The conversion could join all strings instead,
it would be almost backward compatible, as we would alter only conversions
that failed previously.
         I believe we should allow that; I can not wait for the bike-shedding
about which character or string we should use to join them.

     2.2 How much we can break?

         Is missing data in the result of a conversion a reasonable cause to
break behavior? For example "QVariant(QColor) -> QString" doesn't include the
alpha channel (QTBUG-37851).
         As I said in 1.2, I think that we should take the approach of the
best effort and nobody should depend on the exact result of a conversion. We
should reserve our right to improve it, so the best effort is not a lie.

     2.3 How to decide if a conversion should be improved?

         A conversion may be arbitrary. For example, most of the conversions
to QString. Should "bool(false) -> QString" return "False", "0", "false"? What
about precision of, for example, "double -> QString" ?


  3. Can we remove existing conversions?

     I would say, no, but maybe in a major release.

Cheers,
  Jędrek
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list