[Development] QML engine changes
andre.poenitz at mathematik.tu-chemnitz.de
Tue Jun 25 22:54:45 CEST 2013
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.
> 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
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.
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.
It's understandable, to certain degree, to rate one's physical ability to
implement 100% ECMA conformance for certain chunks in a file higher then
the resulting costs. But there is a limit on where it makes sense from a
more "objective" point of view.
More information about the Development