[REVISED] API change proposal: Disallow `super` calls in <state> methods

[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 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.

[David Temkin]

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.
>
>

[Dave Miller-7]

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]

Good point!

On Thu, Jul 24, 2008 at 1:58 PM, Dave Miller <dwmiller@...> 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
hminsky@...