On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote: > The language "barrier" between C++ and QML makes it easier to see where UI > ends and program logic begins, leading to better abstraction between core > application and its interface.
The compulsory QML/JS - C++ language cut generates otherwise uneeded work on the user side as well as significant tooling (refactoring, debugging, profiling...) problems. In a typical Qt Quick application the cut usually goes straight through the middle of the Controler part of a classical Model-View-Controler setup, i.e. sits in a pretty bad (and expensive...) location. It's a sink of resources. Sure, in theory, with a lot of discipline, project policy, and some luck in prediction making, it would be possible to e.g. do only View related things in QML/JS and align the language cut with the View-(Controler and Model) cut, but in practice any crossing of the divide takes some effort and so it's often "easier" to simply do some of the Controler work on the QML/JS side (read "make the bindings a bit more complex"). On the other hand there are (at least for non-toy applications) Controler bits that need to live on the C++ side for performance reasons. So parts of the controler do end up in QML/JS, others in C++, putting the language cut in an awkward place. Having M/V/C boundaries not properly "worked out in code" while developing a long lived application is not necessarily bad, as long as one keeps the idea in mind, and properly does the separation on an as-needed base as the application grows and gains in functionality. If the project is "unilingual" this usually just means introducing some interface and some mechanical refactoring, often enough supported by "native" tooling for the chosen languange. Having an enforced language break in the system takes away this flexibility, leaving essentially the options (a) to accept the need to re-write parts of the system in the "other" language once the time comes, or (b) to use a waterfall style development model, fix the V/M/C boundary before coding starts (and ignore future uses that might need some wiggling). I presume we agree that neither sounds good. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development