Btw, I added this test, and another state related one, and they work (as it did before).
I expect to have something for re-review today. On Mar 14, 2011, at 2:27 PM, P T Withington wrote: > 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. > -- Don Anderson Java/C/C++, Berkeley DB, systems consultant voice: 617-306-2057 email: [email protected] www: http://www.ddanderson.com blog: http://libdb.wordpress.com
