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.
