[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
compliant.
Simon
More information about the Development
mailing list