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: [email protected] Sent: September 28, 2016 17:37 To: [email protected] 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
