Good point! On Thu, Jul 24, 2008 at 1:58 PM, Dave Miller <[EMAIL PROTECTED]> wrote: > 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. >>> >>> >> > >
-- Henry Minsky Software Architect [EMAIL PROTECTED]
