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

[Simon Hausmann]

Hi,


I'm somewhat torn about the behavioral change. One the one hand it's the "correct" thing to do,

on the other hand it does have the potential of breaking existing code.


That said, this is not quite the same as changing the return type of a typed C++ function. QVariant is designed

to hold any type and if you receive a QVariant it has always been a little dangerous to rely on specific conversion

behavior (throughout Qt).



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, September 26, 2016 9:37:07 AM
To: development at qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null

On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote:
> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> > Hi,
> >
> > Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> > showed that the recent change[2] which changes the semantics of null
> > assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
> > code.
> >
> > Certainly, the cases which are affected are most likely edge-cases (that
> > is, specifically testing the type or value of the QVariant within C++ code
> > to detect "null" assignment), however it is probably worth raising for
> > discussion.
> >
> > Why was the change made?  The commit message tells us what was changed,
> > but
> > not the reasoning behind the change.  The unit tests were changed, so the
> > behaviour change was clearly intentional (and the old behaviour considered
> > problematic), and I assume that there must be very good reasons to make
> > such a change, but it wasn't discussed on the mailing list, so I don't
> > know
> > what those reasons are.
> >
> > Best regards,
> > Chris.
> >
> > [1] https://codereview.qt-project.org/#/c/170491/
> > [2] https://codereview.qt-project.org/#/c/167062/
> >
> >
> > www.qinetic.com.au<http://www.qinetic.com.au> - Qt And QML User Experience Specialists
>
> Hi,
>
> There are many reasons, mostly related to C++11 (in more or less
> chronological order):
>  - 5.8 depends on C++11 that has null defined sensibly so we want to use it
> to mark null values.
>  - std::nullptr_t became registered type which is meant to be use for null
> values
>  - QJson support got better null handling (the feature was waiting for
> std::nullptr_t in metatype)
>  - using (void*)0 for null in QVariant was suboptimal as it could not detect
> invalid states like for example (void*)1

Those are the reasons that enabled the change, not a justification for why it
is better (except the last one, which I don't agree; you can always check the
value).

Repeating Chris's question: is it worth the breakage on the user code?

--
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/20160926/7349cedf/attachment.html>