[Development] Toolability of mixing QML and JS
Mohamed Fawzi
Fawzi.Mohamed at digia.com
Thu Jun 27 10:55:34 CEST 2013
On 26 Jun 2013, at 14:26, Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
>
> On 26 Jun 2013, at 12:00 PM, Thomas Hartmann wrote:
>
>>> - Editors: A lot of IDE's out there understand .js files. Writing a parser for only the declarative parts of QML is relatively easy. Writing a parser for .qml files that also understands all of JS, not so easy.
>>
>> We provide a QML parser that includes Java Script as open source. Anyone
>> who wants to parse QML is most likely to use this one and even if not he
>> has access to the complete grammar. So this is not really an issue.
>
> I see it as an issue if you had to write that parser. No wonder it's out of sync with the actual language parser. The one in declarative should have all the features that you need, with suitable (ideally even public) APIs to access those features, it should be in the declarative module, and there should be autotests to keep it consistent. So the workflow for tooling should be that you use the declarative parser to get the AST, the tooling has the opportunity to modify the AST whenever the user does something, then you can send it on to the engine for rendering a preview, and you can also regenerate the source code by pretty-printing the AST. That means the AST must be complete: it must include Javascript (even if they are only unmodifiable blobs) and comments, so that the pretty-printing will generate the same source code with only the changes the user wanted to make. But for optimization purposes there could be a parameter to the parser to ignore the comments, because
> tooling needs them whereas the interpreter does not.
Not sure what you mean here, "that parser" is generated automatically from the declarative parser, and should be up to date.
I you know places where the parser is outdated (which would be strange seeing from where it comes) please file a bug (from your talking it seems common knowledge, but it definitely isn't so).
Creator cannot use the declarative parser directly for a couple of reasons:
* we want more recovery when things fail, as while editing it is easy to have incorrect code
* creator is not bound to a single qt version, so to work consistently it needs its own version
Parsing a language, doesn't mean tooling and understanding it.
More information about the Development
mailing list