[Development] QML engine changes

[Alan Alpert]

On Mon, Jun 24, 2013 at 2:58 PM, André Pönitz
<andre.poenitz at mathematik.tu-chemnitz.de> 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.

Because there's a reason that it's "typically span not more than half
a line" instead of "always span not more than half a line". We do see
more advanced ECMAScript usage inside QML files, occasionally it's
even a valid use case. So we need a complete language with a full
specification for these edge cases, and either we make a new one
arbitrarily which will be the exact same as ECMAScript for all common
cases... or we keep using ECMAScript and maintain the previous and
well-loved feature set.

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

We already have a domain specific language, it's called QML and its
domain is declarative UI. Part of this language is that you can embed
imperative scripting snippets as property bindings, functions and
signal handlers. Either we eat the imperative part into QML and make
it a confusing cross-paradigm mess, or we maintain a "separate"
language for that so that we can clearly differentiate the imperative
and declarative parts. Even if we eat it and get an
imperative-QML/declarative-QML split, we want maximal focus on
declarative-QML and we want imperative-QML to be just some simple,
generic-scripting language that we can spend less time on.

Okay, let's build a language that's perfect for the task at hand for
embedded script in QML. Top needs are:

-imperative scripting language
-implicit typing
-C-like syntax

JS already exists, provides all these abilities, and gets bonus points
for the established base of users and generic libraries. I'm not
saying I like JS, it's one of my least favorite languages. But it's a
well-known generic scripting language that we can throw in without
over-loading new users. Using JS fits all our needs well and means we
can focus on evolving the QML declarative language instead of a
scripting language. So it makes sense to use full ECMAScript in QML
even without getting into the "the masses chose JS" argument, or the
backwards-compatibility argument, both of which are also reason enough
to maintain a full ECMAScript engine.

I would be interested to hear your toolability complaints about JS
embedded in QML, but that's a separate thread. They're probably valid
concerns, but it might be just as easy to deal with them in V4 as it
is to deal with them by writing a new language.

--
Alan Alpert