[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