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

[P T Withington]

I just made the same observation in my review (not yet finished):

lzx> (function ():Boolean { return void 0; })()
false
lzx>

If I try this same test with Number for Boolean in the debugger, it  
seems to fail silently.


On 2008-10-21, at 12:20EDT, André Bargull wrote:

> If a function's return type is Number, you must not return ? 
> undefined?:
> - either remove the return type
> - or return ?NaN?
> (Because AS3 coerces ?undefined? automatically to ?NaN?. By  
> returning 'undefined', we'll get different behaviour across runtimes.)
> For example LzAudio#getVolume(), LzAudio#getPan() and the  
> counterparts in LzView.
>
> I guess it's the same with Boolean. So if the return type is  
> Boolean, returning 'undefined' will produce different behaviour  
> across runtimes.
> For example in LzAnimatorGroup/LzAnimator#update(), #checkRepeat()  
> you can safely return ?false?.
>
>
>
> On 10/21/2008 5:45 PM, André Bargull wrote:
>> Was it already decided how to declare return types in LZX? So, how  
>> to name the attribute which specifies the type? It's now named  
>> "type", any other proposals? Like "return" or "returns"?
>> Any cast needs to be: "foo cast Bar", "Bar(foo)" is only available  
>> in plain AS3 code, in cross-runtime code the latter form is a  
>> function call. (That's why DHTML broke for you.)
>>
>> We should consider to drop the lowercase "type"-declarations for  
>> <attribute> and instead prefer the JavaScript alternatives, because  
>> you need to use the Javascript-form anywhere else (typing for  
>> function arguments, variables, function return types).
>>
>>
>>> Change 20081021-dda-p by dda at lester.local <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>>> > 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 <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>>> >
>>> www: http://www.ddanderson.com
>>
>>