[Development] Behaviour change in QML in Qt 5.8 regarding null

[Simon Hausmann]

Hi,

I don't think the QVariant interface is deprecated, but it just inherently unsuitable for JavaScript specific things such as distinguishing undefined from null or storing function closures. That is why the engine supports both, for different purposes.


Simon

From: thiago.macieira at intel.com
Sent: September 28, 2016 17:37
To: development at qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null


On quarta-feira, 28 de setembro de 2016 08:54:10 PDT Simon Hausmann wrote:
> Hi,
>
> Ok, let me clarify: When the JavaScript engine wants to map a JS null value
> to a QVariant, it used to use
>
>     QVariant(QMetaType::VoidStar, (void *)0);
>
> and now uses
>
>     QVariant::fromValue(nullptr);

Neither is isNull() == true.

> If a string is to be converted to a QVariant, it will naturally use
> QVariant(thatString). I think if that
> string happens to be a null QString, then QVariant isNull() will return
> true, right?

Right. he question was whether QML strings were guaranteed to be non-null. If
you can't guarantee that, then we can't rely on QVariant::isNull().

> If that is unsufficient for the pim code here (or generally any other code),
> then my recommendation
> would be to change the signature to take a QJSValue instead of a QVariant.
> The engine supports that
> transparently and the QJSValue API allows distinguishing between a
> JavaScript null and a string, etc.

Are we deprecating the QVariant interface?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160928/94937776/attachment.html>