[Laszlo-dev] For Review: Change 20081021-dda-p Summary: Add return type declarations to SWF9

[Donald Anderson]

Change 20081021-dda-p by dda at lester.local on 2008-10-21 10:03:53 EDT
     in /Users/dda/laszlo/src/svn/openlaszlo/trunk-a
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Add return type declarations to SWF9

New Features:

Bugs Fixed: LPP-7031 (swf9 back-end is dropping return type  
declarations)

Technical Reviewer: ptw (pending)
QA Reviewer: promanik (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:

     WEB-INF/lps/server/src/org/openlaszlo/sc/ParseTreePrinter.java
     WEB-INF/lps/server/src/org/openlaszlo/sc/SWF9ParseTreePrinter.java

       Explicit return types like Boolean in 'function foo () :  
Boolean { }' were
       not being emitted by the SWF9 backend.  The fix was  
straightforward,
       the fallout was not...


     WEB-INF/lps/server/src/org/openlaszlo/compiler/NodeModel.java
     WEB-INF/lps/server/src/org/openlaszlo/sc/Method.java
     WEB-INF/lps/server/src/org/openlaszlo/sc/Function.java

       Added a "type" attribute to <method> to set the return type.
       This was needed to get a few cases where lzx code overrides LFC  
functions (now with return typing!)
       to compile.  This type must be 'Javascript' (i.e. Boolean, not  
'boolean' is used).
       Some cleanup to reduce the number of constructors for Method/ 
Function.  I think
       this makes the code a bit clearer.

     lps/components/base/datalistselector.lzx
     lps/components/base/listselector.lzx
     demos/lzpix/app.lzx

       Added type="Boolean" to a few methods that override to allow  
them to compile and
       run in SWF9.


     Fixing return typing exposed a lot of 'new' typing in LFC and  
some in application code,
     which caused various consistency errors in several categories.

     - in many .lzs files, functions marked as returning a type did  
not always
       explicitly call return, or when they did they did not return a  
value.
       Initially, I tried to make intelligent guesses about values  
returned (favoring 'null'),
       but testing revealed many problems.  Ultimately, I needed to be
       very conservative, returning 'undefined' in most cases, and false
       for Boolean functions.  This seems to be the default behavior  
for JS
       when returns are missing values.  Cases that seemed most  
questionable
       I marked with:
           TODO: [20081020 dda] review this return value change from  
LPP-7031


     - in several .lzs files, functions marked as override did not  
always match return types.


     - in several .lzs files, toString() is marked as :String, but in  
others it is not.
       For the moment, it was too big of a job to fix all these as  
part of this (already
       large) commit, so typing for this function was commented  
whenever a
       compile error showed a mismatch.


     - in several .lzs files, functions with new typing returned a  
value but without proper typing.
       Type casting was added as appropriate.


     WEB-INF/lps/lfc/kernel/swf9/LzMouseKernel.as:

     - type of a local variable wasn't narrowly typed enough, leading to
       errors in return statements.


     WEB-INF/lps/lfc/debugger/LzDebug.lzs:

     - __StringDescription() needed to be defined with exactly the  
same argument signature
       I don't know why return typing exposed this as a problem.


     WEB-INF/lps/lfc/data/LzLazyReplicationManager.lzs:

     - Certain local variables typed as LzView needed typing  
commented.  Initial attempts
       to fix the typing errors in this file involved casting, e.g.
              var v:LzView = LzView(this.getNewClone( true ));
       But these changes broke smokecheck for DHTML.  It seems that  
some assumption
       about typing is being violated and will need to be tracked down  
later.
       I commented out the typing for the local variables, and left  
TODOs to clean
       this up later.


    Note that the compile errors fixed here only show up when building  
the LFC (or app) for SWF9.
    In debugging these problems it was most helpful to build the  
debuglfc to get line number information.

Tests:
    tests: (smokecheck) * (swf8+dhtml)
    apps: (weather+lzpix) * (swf8+swf9+dhtml), hello(swf9)

Files:
M      WEB-INF/lps/lfc/kernel/swf9/LFCApplication.as
M      WEB-INF/lps/lfc/kernel/swf9/LzMouseKernel.as
M      WEB-INF/lps/lfc/services/LzAudio.lzs
M      WEB-INF/lps/lfc/debugger/LzDebug.lzs
M      WEB-INF/lps/lfc/debugger/platform/swf9/LzFlashRemote.as
M      WEB-INF/lps/lfc/debugger/platform/swf9/LzDebug.as
M      WEB-INF/lps/lfc/views/LaszloView.lzs
M      WEB-INF/lps/lfc/controllers/LzAnimatorGroup.lzs
M      WEB-INF/lps/lfc/controllers/LaszloAnimation.lzs
M      WEB-INF/lps/lfc/data/LzLazyReplicationManager.lzs
M      WEB-INF/lps/lfc/data/LzReplicationManager.lzs
M      WEB-INF/lps/lfc/data/LzDatapointer.lzs
M      WEB-INF/lps/lfc/data/LzDataText.lzs
M      WEB-INF/lps/lfc/data/LzDataNode.lzs
M      WEB-INF/lps/lfc/data/LzDataElement.lzs
M      WEB-INF/lps/lfc/data/LzDatapath.lzs
M      WEB-INF/lps/lfc/data/LzResizeReplicationManager.lzs
M      WEB-INF/lps/lfc/data/LzParam.lzs
M      WEB-INF/lps/lfc/data/LzDataAttrBind.lzs
M      WEB-INF/lps/lfc/compiler/LzBootstrapDebugService.lzs
M      WEB-INF/lps/server/src/org/openlaszlo/sc/Method.java
M      WEB-INF/lps/server/src/org/openlaszlo/sc/ 
SWF9ParseTreePrinter.java
M      WEB-INF/lps/server/src/org/openlaszlo/sc/Function.java
M      WEB-INF/lps/server/src/org/openlaszlo/sc/ParseTreePrinter.java
M      WEB-INF/lps/server/src/org/openlaszlo/compiler/NodeModel.java
M      lps/components/base/datalistselector.lzx
M      lps/components/base/listselector.lzx
M      demos/lzpix/app.lzx

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081021-dda-p.tar



--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-547-7881
email: dda at ddanderson.com
www: http://www.ddanderson.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20081021/cae8f33c/attachment-0001.html