[Development] Converting types in Qt

[Ziller Eike]

On Jul 15, 2014, at 7:36 PM, Olivier Goffart <olivier at woboq.com> wrote:

> On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
>> Olivier Goffart wrote:
>>> Jędrzej Nowacki wrote:
>>>>  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.
>>> 
>>> I'd say yes, for sensible conversion
>>> You are right that it is a behaviour change, but i think it is worth
>>> changing it.
>> Why?
>> 
>> On one hand you promise binary compatibility. On the other hand
>> behaviour changes are proposed to be done on an "nice to have"
>> base?
>> 
>> Do we really think that's ok to disallow changing some int foo() { return
>> 42; } to some int bar() { return 42; } that's easy to discover at build
>> time, but it's fine to change int foo() { return 42; } to int foo() {
>> return -1; } ?
> 
> It's always a dilemma. We have to look at how likely we are to break 
> applications and I don't think adding a conversion is likely to cause 
> breakages.
> 
>>> 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>
>> 
>> QVector<char> v; v.append(130);
>> QLinkedList<int> l = /*some"Sensible"AutomatedConversion*/(v);
>> 
>> assert(l.first() == 130) ?  "Depends" ?
> 
> QVariant(char(130)).toInt() already exists. You may argue that it is not 
> sensible but that's another issue.
> I guess the example is more between QVector<T1> -> QLinkedList<T2> when there 
> exist a conversion from T1 to T2
> 
>>>>         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" ?
>>> 
>>> We use common sense on a case by case basic.
>> 
>> I tend to believe the common sense in type conversion land is pretty
>> close to "avoid to do it automatically, prefer to make it explicit".
>> 
>> Already now it's far too easy to make mistakes based on the "nice
>> and easy" QByteArray -> QVariant -> QString conversions when
>> accidentally writing QByteArrays into QSettings and reading QStrings
>> back. There shouldn't be more of that.
> 
> What's the mistake here? Wrong encoding? Bad performances?

wrong values & unexpected results

> When one use QVariant, it is because we want to enjoy dynamic typing and nice 
> conversions.

I don’t think we have a single place in Qt Creator where we want automatic conversions when using QVariant. A search for QVariant(Map) returns 5400 hits.
In the map case, we usually expect the one retrieving the value for a key to know the exact type of what was thrown in (that’s usually the same class, or related classes), and then we use item models and QSettings which we use in the same way.

Even if automatic conversion might be interesting (when, actually?), then the point is:

There is no API in QVariant to support the common use case of getting the value *without* automatic conversion.

>>> We use common sense on a case by case basic.


Either there is no “common sense” common to me, or this rule has failed in the past already ;)

bool -> string ?
bytearray -> int/long/double ?
keysequence -> int ?
string -> bool ?
string -> bytearray ?
string -> int ?

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B