On Thu, Nov 14, 2013 at 8:01 AM, Topi Mäenpää <[email protected]> wrote: > On 11/14/2013 04:43 PM, Robin Burchell wrote: >> On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää <[email protected]> >> wrote: >>> Or rather could, if the interface wasn't a moving target. >> >> If an interface is a moving target, that means that trying to promise >> compatibility for it is generally a bad idea. > > I don't quite get this. Can you elaborate? I was trying to say that the > stuff I'm trying to do is doable in principle as proven by the couple of > different implementations made so far. But every new release of Qt makes > me hold my breath because I know I have used features that aren't > promised to be available. > >> Once something is made public, you're stuck with it. For a very long >> time, and maybe even forever if people get too attached to it. You >> can't go back on that, so you need to be very, very sure you'll be >> happy with it. As evidenced by the v8 to v4vm change, we aren't there >> yet. And once we do expose it, we tie our hands from making future >> changes that might be in our benefit. > > This is true, but also a common excuse. I have seen it being used to > block quite a few feature requests in many projects. Now, however, we > already have a pretty good API definition: QScriptEngine already > provided just about everything that was needed. All those things are > doable in v8, and I bet also in v4vm. It is just a matter of writing a > few interface classes that hide the implementation details. That would > free extension developers from the burden.
Pick the wrong interface classes, like QtScript did, and you suffer in the long term. That's why we aren't committing to anything more than the overly basic QJSEngine API just yet. As I understand it, the long term plan is to extend the QJSEngine APIs and drop QtScript (and add QtWebEngine). Then for application scripting purposes you can use QML/JS for QObject integrated scripts or generic JS and it will work for the cases previously fulfilled by QtScript (and use QtWebEngine for HTML5/JS scripts). V4 integrates better with Qt than V8 did, so as an application scripting addition to the Qt framework it does have better potential (and QtWebEngine will have access to the platform browser's JS engine if you need something for big scripts with no or minimal application integration). Ways it integrates better includes: Faster for jumping in and out of JS, faster when dealing with Qt types, runs on all platforms Qt does, potential for better Qt Creator debugging and of course tighter QML integration. So providing a JS engine for application scripting is less of an "afterthought" and more of a "second stage" once we finish the QML engine rewrite. But that's a long term plan, v4vm isn't even released yet (new in 5.2 remember) and there's still tons of work to do. Until v4vm is ready to take over from QtScript, which will still be a while, I believe the recommendation is to keep using QtScript. It's deprecated and "done" because we've reallocated development priorities, but until we've finished its replacement it is your best option. Even though it means using old or no QML, it sounds like the JS support is more important for you. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
