[Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki <jedrzej.nowacki at digia.com> wrote:

> On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
>> [...]
>>> 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.
> 
> Nobody asked for it, It should be easy to implement something equal to this;
> 
> Q_ASSUME(variant.userType() == qMetaType<TargetType>()); 
> TargetType data = variant.value<TargetType>();
> 
> I believe such new api make sense, we can add it.
> 
>> 
>>>>> 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
> 
> What is wrong with string -> int or bytearray -> int?

First of all I wondered what bytearray -> int does at all. Convert the first byte in the byte array to an int, if bytearray.size() == 1 (which would be consistent with QStringList->QString)?
bytearrays are not strings after all…

Otherwise bytearray/string -> int has similar problems as string -> bool and string -> bytearray:
There is no canonical “right” way to do it, and it can fail depending on the actual *value*. Does QVariant::canConvert actually take that into account? Is there any other possibility to find out if it went wrong? Does it interpret 0xa1 ? Will 076 be interpreted as octal or decimal?
Does it convert “𝟷” (U+1D7F7) to 1 ? ;)
All in all it creates more questions than it solves problems.

There are no QKeySequence::toInt(), QString::toBool(), QString::toByteArray() functions btw, and QString/QByteArray::toInt(…) take arguments. I think one prerequisite for possible conversions (automatic or not) should be, that a corresponding ::to… function without any arguments in the corresponding type would survive an API review, and actually is added as well. Then one also has a place to look for documentation how the actual conversion is done.

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 
> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

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