[Development] Question about Qt's future

Joerg Bornemann joerg.bornemann at digia.com
Mon Apr 28 18:02:53 CEST 2014


On 28-Apr-14 16:36, Sze Howe Koh wrote:

> To check if I've understood you correctly: You've found that
> classifying QML as "declarative" distorts developers' expectations of
> the tools?

The term "declarative" is mainly used here as a synonym for "perfectly 
toolable". So yes, I would expect that every QML file, regardless of who 
has written or what has generated it, is perfectly editable in a WYSIWYG 
design tool. Like .ui files, you know.

> Do you think it will help if we rebrand QML as a "markup language" or
> a "multi-paradigm language", instead of a "declarative language"?

Unless I misunderstand what QML (sans JS) consists of, it's everything 
but JS imports and the right-hand-side of bindings == an unusable 
subset. Therefore the dinstinction between "declarative QML" and 
"non-declarative QML/JS" is artificial and has no value in practice.
But I also don't think a "rebranding" would help much.

> Some user interface markup languages (e.g. XAML, MXML, HTML) allow
> imperative code to be embedded within declarative code.

Yes and of course that's needed for more complex things. But all those 
have a clear boundary between language XY and JavaScript. The boundary 
between QML and JS is blurry. What would help is a clear definition what 
subset of JS is in the declarative part of QML/JS.
The list could start with
    - literals (obviously)
    - standard operators (which?) on built-in types (only JS types? Qt 
types?)
    - side-effect free standard library functions

One should be unable to use anything but this JS subset in .qml files 
(Hooray! This file is toolable!). Everything else should go into .js 
files (You're leaving the toolable sector!).



BR,

Joerg



More information about the Development mailing list