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

[David Temkin]

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.
>
>