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....@qt-project.org
[development-bounces+thomas.hartmann=digia....@qt-project.org] on behalf of
Thiago Macieira [thiago.macie...@intel.com]
Sent: 28 April 2014 02:34
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
