Am 18/12/2012 00:53, schrieb André Pönitz: > But back to the original issue, within the intended context: The > point is that with the existence of arbitrary imperative blobs with > arbitrary side effects and full access to global data a language's > claim to be "declarative" is hard to defend - both in theory, and in > practice.
True. Once you have any imperative JS code or any binding to a function with side effects in QML it is clearly not declarative anymore. From the tooling side it is important to emphasize that there is a declarative sub lanugage "hidden" in QML that we can provide tooling for. But complete QML, including full imperative JS, is not declarative at all. Actually the next version of Qt Quick Designer will explcitly warn about imperative code it finds. Every feature properly supported by visual tooling has to be purely declarative. From the tooling side, not having a strict distincion between declarative and non declarative QML, is problematic at least. We still play with the idea to introduce something like a .qmlui format, which strictly enforces purely declarative QML. The reason we did not so (yet), is that in about 90% of the cases the imperative code is not relevant for the visual design and can be savely ignored by the tool. (e. g. the handler of a button clicked signal). Having that in mind I strongly propose a purely declarative api for actions in QML, if we want to support them in the tooling. Having addiontal imperative APIs is not a show stopper, but we will not support them. Also it has to be 100% that because QML is so much more verbose than .ui files and it includes a turing complete language (JS) there will always be QML files that do not benefit from any visual tooling. Which is not a problem in pratice at all. Kind Regards, Thomas Hartmann _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
