[Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Simon Hausmann]

On Tuesday 29. April 2014 10.51.36 Alan Alpert wrote:
> On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas
> 
> <Thomas.Hartmann at digia.com> wrote:
> > Hi,
> > 
> > On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz <apoenitz at t-online.de> 
wrote:
> >> I think at least three modifications are inavoidable: For one, things
> >> that
> >> could be written in a declarative way but which currently are only
> >> possible
> >> using JavaScript, a declarative way should be added. Second, it should be
> >> stressed in the documentation (including the examples), that using
> >> inline imperative code is naughty. This can be supported by e.g. the QML
> >> Designer refusing to operate on such files. People can still do that, but
> >> would be on their own. And finally, and that's also acting as a proof
> >> that
> >> the first two items actually have been done, the JavaScript dependency
> >> should be _optional_.
> > 
> > Can we turn this into action points we _all_ agree on?
> > My personal favorites are (In no strict order):
> > 
> > (1) Identify non declarative parts of Qt Quick and add declarative API
> > (e.g. setting states)
> Agreed. This is my personal favorite ;) .

Can you elaborate a bit with an example what this means?
 
> > (2) Document that inline Java Script and mixing declarative and imperative
> > code in one file has its pitfalls in big projects and creates issues for
> > tooling. Explain the difference between pure declarative QML and QMLJS
> > and the impact on tooling.
> Agreed.
> 
> While I think that mixing declarative and imperative code in one file
> has it's advantages in small projects, there should be a clear line
> between "pure declarative and toolable" vs "you're on your own". I'd
> like to see something like ".pragma declarative" which defines this
> line, such that if you add ".pragma declarative" un-toolable JS blocks
> or bindings become compile errors.
> 
> > (3) Document that accessing ids from other .qml files without any
> > interface (just relying on the fact that they are in the context) creates
> > hard to maintain QML code.
> Agreed (honestly, it should already be there, I guess
> https://bugreports.qt-project.org/browse/QTBUG-20453 was never
> finished...).
 >
> Again, we have some rough plans for a ".pragma strict". Which should ban
> this.

I'm personally not convinced about a .pragma strict yet, but I would like the 
idea of either selectively or globally enable checks in the engine that will 
print out a warning when for example an id is looked up across the context 
boundaries. That should be relatively easy to do. We might even be able to 
detect some of these situations at type compile time, but it's a little harder 
naturally.

> > (4) Writing (more) QML(JS) static analyzers that can check/enforce a
> > proper strict mode for QML.
> Agreed, see ".pragma strict" comments. Speaking of which, this idea
> has been around for a while:
> https://bugreports.qt-project.org/browse/QTBUG-30069

Yeah, we should use that jira entry to track efforts around that.

> > As a second step the actual work has to be done of course.
> 
> Yeah, that's always the biggest issue... Every time these discussions
> come up there's no major theoretical point of contention. It's just
> that the work still hasn't been done and we all like arguing.

Which I suppose it's most important to break it down into smaller pieces. 
Instead of a general re-design, perhaps there are things that we can do more 
incrementally. That's why I for example would like an equivalent of "-Wall" at 
run-time to begin print out a warning when we detect behaviors that we are bad 
practice (i.e. id lookup across context boundaries).

Perhaps we should start with that. Any suggestions for additional behaviours 
we should warn against at run-time (or type compile time if possible)?


Simon