[Laszlo-dev] API change proposal: Disallow <method> in <state>

[P T Withington]

[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 <method> tag is not permitted in the <state> tag.

2) Introduce a new tag, <function>, which is allowed anywhere <method>  
is allowed and is also allowed in <state>.  <function> behaves exactly  
as <method> does, except that:

  a) it does not support (what we call) "implicit this" and
  b) you cannot make `super` calls from a function.

In the body of a function, if you want to access the members of the  
instance the function was called on, you must explicitly say  
`this.<membername>`.  Saying `<name>` without qualification in the  
body of a function can only be used to refer to globals, parameters,  
and local variables of the function.

What this means to the LZX developer:

1) If the developer uses <method> in <state>, they will get a compiler  
error saying that it is not permitted.

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.

  b) Dynamically add a method to the parent.

In case a), the <method> can be changed to a <function> and any  
references to instance members rewritten using explicit `this.`  
qualification.

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 implicitly be a function, not a method.  This is an unfortunate  
restriction that will surely cause confusion, but I don't have any  
better solution at present.

---

Note:  The new <function> tag is simply syntactic sugar.

   <function name="x" args="y">body</function>

is completely equivalent to:

   <attribute name="x" value="function (y) { body }" />