Multiple Runtimes Infrastructure
From OpenLaszlo
Development Strategy
This is an overview of the work items in the Tasks section.
This plan calls for compilation into "portable JavaScript". This is a dialect of JavaScript that can be executed as it stands, translated into JavaScript that runs on, or translated into bytecode that runs on, any execution engine (Embedded browser JavaScript execution engines, libraries such as Spidermonkey or Rhino, and Flash player versions 7 and higher). The compiler will use portable JavaScript as a compilation target, similar to the use of C and C-- for code generators.
(Question: don't we really mean Flash player versions 6 and higher? ActionScript 2.0 can be compiled to Flash 6 (see the bottom of | this page), and ActionScript 2.0 | is compatible with ECMA-262 Release 3, which is the same as JavaScript 1.5.)
Portable JavaScript is defined as JavaScript 1.5 with these changes:
- The 'class' construct from JavaScript 2.0 is supported.
- Type declarations from JavaScript 2.0 are supported. This is necessary to eke the optimal performance from the Flash 8.5 player. It also has benefits for code self-documentation, documentation tools, and for enabling compile-time and/or runtime type mismatch errors.
- Possibly: prototype-based inheritance is not supported.
- ECMAScript 4 does retain the prototype keyword (see [| Miscellaneous Attributes])
- However, ActionScript 3.0 may impose limits on the use of prototype-based inheritance, and since swf9 support is a requirement of this work we may need to conform to those limits.
- Compiler:
- Implement a JavaScript back end. This can be connected to the Flex compiler in order to allow runtime development to proceed in parallel with development of a native compiler. It can also be used to produce the js files for browser inclusion.
- Implement a swf9 back end.
- Add support for @class@ and type declarations.
- Runtime:
- Define a display list node abstraction that interfaces between the JavaScript and the runtime display engine. This will have an API that is similar to the Flash MovieClip object, but on DHTML will be implemented as @<div>@.
- Remove references to @_root@.
- Remove or isolate into target-specific libraries direct references to the swf API.
- Rewrite code that relies on bashing the protoype chain (which is not supported in swf9 and in DHTML IE). This requires the introduction of the @class@ keyword for portably defining classes, the removal of @LzTransformer@, and the reimplementation of states.
- Rewrite code that relies on undefined variables acting as @null@ and @function(){}@.
Proposed Milestones
- Compiler can generate JavaScript output for runtime library, that runs in Rhino.
- Compiler can generate JavaScript output for the demo applications.
Tasks
These are tasks in common with supporting swf9 and DHTML. Tasks specific to swf9 are listed on the SWF9 Target page.
Basic Functionality
These tasks are necessary in order to get up and running.
Compiler: Generate JavaScript
Add a compiler back end to generate portable JavaScript (ECMAScript Release 3 or JavaScript 1.5, as described above). A compilation mode would create a pure JavaScript representation of a program; e.g.:
> lzc --target=javascript hello.zx
Portable JavaScript is generated by compiling out conditional compilation directives, type declarations (below), and 'class' declarations (below).
Compiler & Runtime: Implement 'class' keword
moved to JIRA
Doc Tools: Parse 'class' keyword
Modify the doc tools to parse the 'class' keyword. This enables the following task, to modify the runtime sources to use 'class'. LPP-942
Runtime: Re-implement states
States use prototype bashing. Rewrite to directly modify the object properties.
Runtime: Use classes
Replace the prototype bashing in the runtime with the use of the 'class' keyword. This prepares the runtime to compile to swf9 and IE. LPP-943
Runtime & Components: Remove Undefined Variable References
The runtime library depends on the fact that we don't trigger an error when accessing an undefined variable. This won't work for the default compilation settings for swf9, and for DHTML. Define these variables. For swf9, this can be done incrementally, because the Flex compiler support a compilation mode to turn off this error detection, which can be invoked on a file by file basis.
Compiler & Runtime: Remove '_root'
(RESOLVED DUP IN JIRA) Remove the use of '_root' as a qualifier for global variables in the runtime sources. This won't work in DHTML. Modify the compiler to define functions within the scope of "with (_root)", and remove _root from the sources. LPP-927
Runtime: Remove LzTransformer
(MOVED TO LEGALS IN JIRA) LzTransformer is no longer necessary, and relies upon prototype bashing that will not work in swf9 or IE. Remove this class. LPP-928
Runtime: Introduce display list abstracton
Modify LzView to use a class that represents the display list node. For swf<9, this class wraps or preprocesses to a movie clip; however, code that references it should be portable to other systems.
Optimization Tasks
These tasks are not necessary to reach functional completion, but will be necessary to meet performance goals.
Compiler: Add Type Declarations
(EXISTS IN JIRA NOW) Add type declarations to the grammar. Update the code generator and doc tools to (for now) ignore them. Update the js back end to strip them, when compiling for targets that do not support them (e.g. the generic dhtml target). LPP-944
At the end of this task, you will be able to compile code such as:
function f(a :Number) : Number {}
(Note: this part of the JavaScript spec is in flux. The current ECMAScript 4.0 spec says
function f(a as Number) as Number {}
instead. We will track the spec; if it doesn't appear to be stabilizing quickly enough we will choose the first notation, and change if we need to in a later task.)
This is necessary to take full advantage of the swf9 performance improvements. It is also a common request (along with compiler warnings for type mismatches, which this task itself does not implement).
Runtime: Use Type Declarations
Cleanup Tasks
Source organization: Rename *.as -> *.js
Rename the runtime library source files to *.js, to indicate that they are not specific to ActionScript.
Doc tools: Use Type Declarations
Change the doc tools to use the type declarations instead of (or in addition to). This task is optional because the existing comment annotations can be left in.
