[Development] QML engine changes

Simon Hausmann simon.hausmann at digia.com
Tue Jun 25 11:14:27 CEST 2013

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.

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?

To me the best question to those answers is simply: Just be fully spec 


More information about the Development mailing list