[Development] QML engine changes

[André Pönitz]

[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.

Andre'