On Thu, Nov 27, 2014 at 08:13:32AM +0000, Koehne Kai wrote: > > [...] > > Still - the only guarantee you get with a specific import version is that > > of the > > API, but not the behavior. Thus, it's perfectly possible that someone swaps > > the libs and your app *IS* affected. See for example the "QML instantiation > > performance thread". You likely won't blow up, but far from "can't be > > negatively impacted" by having the lib updated behind your back. > > > > To add insult to injury, it's actually pretty hard to find out what was > > introduced when, so your imports will reflect "which version of Qt I > > developed my app with" rather than "what Qt features does my app > > require". > > Well, this isn't a problem specific to QML versioning, is it? A bug fix in Qt > might also break your existing C++ application if it relied on the old, > 'broken' > behavior.
Right. That's why behaviour changes should be kept to a minimum in general, restricted to "obvious" bug fixes, performance improvements etc. Of course this is a grey area, and people do not alway agree on what's reasonable (see e.g. the thread about conversions via QVariant) But they are easier to cope with in C++ code, at compile, link *and* runtime. Postponing everything to runtime and hoping that the installed version *somehow* mimics the original behaviour well enough for your particular use case is a way to disaster. If at all, this works only on strictly controlled platforms and strict policies for applications, not on open systems. > > #if QT_VERSION >= QT_VERSION_CHECK(5,3,0) > > > > ...why can't we have something functionally equal for QML? > > To be fair, the C++ macro expander is regarded by quite a few people as > a necessary evil, not a feature new languages should aim for ... The proposal was not to use the C preprocessor exactly but something that fits the purpose. > > As it is now, > > whenever I decide to add support for a new feature, I make my QML > > incompatible with older Qt versions (which is understandable) with no way of > > defining a fallback or alternative (which is not OK) regardless how trivial > > the > > new feature is. > > One benefit of QML is that you can do switching between different QML files > trivially at runtime (for example by using a QFileSelector , or by using a > Loader > element ...). Full files are usually not the granularity at which compatibility problems appear. And Loaders. How "declarative"... Andre' _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
