[Laszlo-user] [REVISED] API change proposal: Disallow `super` calls in <state> methods

[Dave Miller]

Just a note, wherever you document it, you might want to explain that  
this stuff applies to only methods that are direct children of states.  
A method that is a child of a view that is a child of a state will  
work as before. Right?

"methods inside states" isn't quite precise enough.

Dave




On Jul 24, 2008, at 10:02 AM, David Temkin wrote:

> This is cleaner. Still will present developers with an unexpected  
> "gotcha" as <methods> are put into a <state>, and "super." is used  
> naively within a <method>.
>
> will this generate a compiler error?
>
> where should this limitation going to be documented? <state>?  
> <method>? language preliminaries? the new JS2 doc?
>
> On Jul 24, 2008, at 5:45 AM, P T Withington wrote:
>
>> [Cf.: http://jira.openlaszlo.org/jira/browse/LPP-5624]
>>
>> In the current system, LZX developers have sometimes written  
>> methods inside states.  As far as we can tell, this is neither  
>> explicitly supported or unsupported, but it happens to work for swf  
>> and dhtml.  It can't work for static runtimes like swf9 (or other  
>> JS2's), because states can be placed, so the compiler cannot tell  
>> at compile time which class these methods really belong to -- they  
>> are dynamically attached to instances at runtime.  We have tried a  
>> number of ideas to work around this issue with no success and  
>> currently this is one of the major roadblocks to getting some  
>> applications working in swf9.  We propose making the following API  
>> change for states:
>>
>> 1) The use of `super` is not supported in <method> tags in the  
>> <state> tag.
>>
>> What this means to the LZX developer:
>>
>> 1) If the developer uses <method> in <state>, they will not be able  
>> to make `super` calls in that method.
>>
>> 2) The developer will need to decide whether the purpose of the  
>> <method> is to:
>>
>> a) [most likely] Simply be a common subroutine that is used by  
>> other parts of the state, e.g., to implement a complex constraint.   
>> It references members of parent, but does not need to use `super`.
>>
>> b) Dynamically add a method to the parent and fully participate in  
>> the class protocols.
>>
>> In case a), the <method> can be left as is.
>>
>> In case b), the <method> will have to be statically added to the  
>> parent (i.e., moved out of the state into the parent).  If the  
>> developer was intending the method to dynamically replace an  
>> existing method in the parent when the state is applied, they  
>> should be aware that only constraints and children are removed when  
>> a state is un-applied, so they may not be getting what they expect  
>> anyways.
>>
>> ---
>>
>> Note:  The body of a <handler> is implicitly a method in a <view>.   
>> Because of the above proposal, the body of a <handler> in a <state>  
>> will not be able to make `super` calls either.  As above if a full  
>> method is required, it should be statically added to the parent,  
>> and the handler rewritten to refer to the static method rather than  
>> using its body as an implicit method.
>>
>>
>