[Development] Question about Qt's future

[Hartmann Thomas]

Hi,

while (at least for me) it is not really clear where exactly the boundary between declarative and functional programming lies, we could/should at least rule out control flow statements and anything with side effects in bindings.

The statement "width: Math.floor(height)" could be considered declarative (enough), if we limit the allowed functions to a well defined subset.

But currentlty one can do this: width: { Any imperative code one can imagine, including loops, while(true) and side effects.  } This clearly is not declarative anymore. 

Another issue with QML is that some parts of the API of Qt Quick are not accessible through a declarative API (e.g. setting a state). While this is not a problem in principle (since we could extend the API), it is a problem in practice. 
Until now nobody (including me) found the time to fix it.

>From my point of view many of these problems are caused by the fact that Qt Quick allows very fast prototyping
(And Qt Quick is an excellent UI prototyping tool.), but is also used in real production code.
While certain features (Like inlining .js code everywhere all over the place and no clear split between declarative UI and logic) are nice for protoyping, they can become a burden in larger production code.

To give a concrete example: While things like width: Math.max(someId.width, someOtherId.width) + magicNumber
are nice to achieve certain complex layouts and to circumvent limitations of the "declarative layout system", they create a huge maintenance burden, because this kind of code is hard to read and does not play nice with tooling.

The only solution I see is to create a well defined QML/QtQuick (sub)set that is more suitable for production code/larger projects. Such QML would be more rigid, enforce more structure on the developer and would be as declarative as possible. 
Such a QML "dialect" could forbid any inline js code. All Java Script could would be part of .js files. 

Another idea is to allow C++ companion objects, that would take the place of any Java Script code for people who prefer C++. A companion object would be a QObject paired with the QML object, that has access to the QML context. The QObject would then define a couple of signals/slots that can be used from QML as Java Script is used today.

Kind Regards,
Thomas Hartmann
________________________________________
From: development-bounces+thomas.hartmann=digia.com at qt-project.org [development-bounces+thomas.hartmann=digia.com at qt-project.org] on behalf of Thiago Macieira [thiago.macieira at intel.com]
Sent: 28 April 2014 02:34
To: development at qt-project.org
Subject: Re: [Development] Question about Qt's future

Em seg 28 abr 2014, às 00:55:12, André Pönitz escreveu:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> > Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> > > Having imperative code on the JS side is also the root of the rejection
> > > of
> > > QML for many C++ developers. If QML would have been just a improved .ui
> > > nobody would have complained.
> >
> > We'd end up with one of the problems of CSS which is that you can't do
> > calculations in the bindings. I can't do
> >
> >     width: 50% - 10em
> >
> > The moment you start adding some math, you need stuff like Math.random()
> > and you end up again in JS.
>
> Not true. Some (basic) math fits the "declarative" needs, and would
> be toolable. Math.random() does obviously not fit the bill.

Math.floor() then.

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