We never succeeded in having that API proposal accepted, AFAIK, because there was too much legacy code that expected to be able to use <method> in states. We _could_ push it through, since what happens when a <method> is compiled in a state is how we proposed to implement <function>, but this would be rewriting a lot of legacy code. Instead, we should just document that such methods can not make super calls (and Don should verify that his optimization does not break instance references in these state methods).
On 2011-03-12, at 20:49, André Bargull wrote: > How should states _really_ work?: >> http://openlaszlo.org/pipermail/laszlo-dev/2008-March/013650.html > > API change proposal: Disallow <method> in <state> >> http://www.openlaszlo.org/pipermail/laszlo-user/2008-July/006900.html > > > On 3/11/2011 9:03 PM, P T Withington wrote: >> Another test case we need to verify: >> >> <class name="stateTest"> >> <attribute name="attr" value="42" /> >> <state applied="true"> >> <method name="stateMethod"> >> return attr; >> </method> >> </state> >> </class> >> >> <state>s are funny in that they 'donate' their methods to the parent node. >> We may have some work to do there. Perhaps we will have to turn off the >> optimization for now and file an improvement to fix the way state methods >> work.
