[Development] QML engine changes

Alan Alpert 416365416c at gmail.com
Wed Jun 26 06:00:45 CEST 2013

On Tue, Jun 25, 2013 at 1:54 PM, André Pönitz
<andre.poenitz at mathematik.tu-chemnitz.de> wrote:
> On Tue, Jun 25, 2013 at 11:14:27AM +0200, Simon Hausmann wrote:
>> On Monday 24. June 2013 23.58.17 André Pönitz wrote:
>> > [Upfront: I am _really_ happy to see V8 and the glue code its service
>> > required to be on its way out. But...]
>> >
>> > On Mon, Jun 24, 2013 at 01:30:18PM +0200, Simon Hausmann wrote:
>> > > > This confuses me a bit.  Why isn't the implementation tuned specifically
>> > > > for QML, instead of being a fully-compliant ecmascript implementation?
>> > >
>> > > Because we want to continue to support the use-case of import "Foo.js" as
>> > > Bar; I've personally used that for a little spare time app I wrote, when
>> > > I was super happy to discover that a piece of functionality I needed was
>> > > available as third-party JS library that I could just exclude. [...]
>> >
>> > This still somewhat leaves the questions why that use case is so important
>> > that it justifies the hoops that need to be jumped through to make it
>> > happen (especially at the expense of more common uses that typically do not
>> > go much beyond arithmetic expressions and an 'if', or an occasional loop),
>> > and why 100% ECMA conformance for chunks of code that typically span not
>> > more than half a line is useful if the full file isn't conforming to any
>> > standard anyway.
>> >
>> > The obvious alternative would be to leave "full ECMA" to separate .js files
>> > (and do whatever needs to be done to make that work) and use inside .qml
>> > only the parts that are typically used in that context, perhaps garnished by
>> > some syntactic sugar to reduce boiler plate, and maybe restricted to the
>> > cases that are easily toolable - i.e. a real Domain Specific Language
>> > addressing exactly the task at hand.
>> I think that this point there are no hoops we need to jump through to get
>> ECMAScript compliance. It was a high priority for during the development
>> (what's done is done) and I think we can maintain the compliance at a very
>> very low cost.
> I was not refering to the hoops _you_ (plural, refering to people in favour
> of the idea) need to jump trough to implement full ECMAScript, but the
> hoops the people working on the tooling side need to jump through to
> somehow cope with the result, and finally the users of such tools who need
> to work with those as a consequence.
> By now I lost count on how many attempts we had at providing somewhat
> decent like a visual design tool for QML, only to see it being obsoleted by
> random backend changes. A complete waste of resources, lasting for years by
> now. Like two weeks were spent alone for getting something as simple as
> hybrid stepping in the debugger betweem JS and C++ into a "somewhat
> working" state. That "success" lasted not even for a month. Etc, etc.
>> Note that plenty of our own examples make use of "pure" JavaScript, and then
>> the question is: Where do we draw the line? At the ECMAScript "classes"? At
>> the exception throwing behaviour?
> You could e.g. go through the current implementation of the desktop
> components and take a survey of the actual JS features used.
> As a first approximation, I would expect drawing the line between the used
> and the unused features there to be "good enough" for practical purposes.
> Some polishing, b; done. Everything beyond that should go to separate .js
> files. If someone wants or needs to use that - fine. But out-of-scope from
> a tooling perspective.
>> To me the best question to those answers is simply: Just be fully spec
>> compliant.
> Complying to some specification is - all other things being equal - a Good Thing.
> However, the "other things" are far from being equal in this particular case.
> Each procedural feature that's available in the "inline" JS in a .qml file
> hurts _badly_ on the tooling side. The more you add, the more it hurts.
> What you do, and what you take pride into achieving, hurts _me_. It hurts my
> work, it eats into my own resources, and more generally into the resources
> of the team on the tooling side, and last but not least into the resources
> available to general development of Qt.

Every individual feature hurts? So you noticed some specific relief
when we deprecated the "with" statement? If you didn't, how would
dropping other features (without dropping the essential procedural
part of QML, such as if, for, while, switch and function) provide

> The staunch refusal to provide reasonable interfaces to the individual layers
> of the Qt Quick stack adds insult to injury, no matter how you put it.

Good thing we never did that. In fact, V4+V8->V4VM and
QtDeclarative->QtQml+QtQuick both promise to improve the interfaces
between individual aspects of the QtQuick stack.

Now maybe these don't solve your specific toolability concerns. But as
you haven't mentioned any specific concerns yet, I can only address
the problems I'm aware of. As I said, I'd like to hear your
toolability complaints about JS embedded in QML, in a separate thread.
It will almost certainly be easier to address them with the new JS
engine than the old one.

Alan Alpert

More information about the Development mailing list