On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki <jedrzej.nowa...@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@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 

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to