Resolving QtScript's "Legacy" APIs

We want Qt to have the best possible JavaScript technology. To make this happen, we need the ability to make drastic changes to the implementation -- even replacing it -- underneath our public APIs. If an API exposes implementation details, that will cause us to limp.

From our extensive work with existing JavaScript engines (JavaScriptCore from the WebKit project, and V8 from Google), we're starting to get a very clear picture regarding which parts of QtScript's C++ API are "universally valid", and which are "universally headache-inducing" to our implementation.

We need a path towards re-enacting the "Run, Forrest, run!" scene from Forrest Gump. To this end, say hello to QTBUG-15571, which serves as a hub for collecting information about, and ultimately resolving, implementation-biased QtScript API. In an ideal world, nobody (other than Qt's own libraries and tools) would be relying on those parts, and we could just click the big "Obsolete" button. However, we don't know the extent of their usage. If you or someone you know is using the API in question, it would be of great help to us if you leave a comment in the corresponding JIRA sub-task. Maybe there are some use cases we missed, too.

Due to source and binary compatibility constraints, we can't (and won't) drop the offending API in Qt 4.x. But it may limp.

Blog Topics: