[Laszlo-dev] [REVISED] For Review: Change 20080728-ptw-G Summary: Implement <setter>

[André Bargull]

>
>> And it's also currently not possible in swf9 at all, see point (iii).
>
> That's too bad.  Possibly a reason for ruling it out.  If this is 
> really not used anywhere in code, I suppose now is as good a time as 
> any to disallow it. 
But at least this is only a restriction from our parser, e.g. you also 
can't call the super-method in bracket notation:

> <class name="base">
>     <method name="dostuff" >
>         Debug.write("base.dostuff");
>     </method>
>   </class>
>
>   <class name="sub" extends="base">
>     <method name="dostuff" >
>         super['dostuff']();
>         Debug.write("sub.dostuff");
>     </method>
>   </class>

compile error:
> |LPP-5587.lzx:36:11: Syntax error: the token "function dostuff ( ) { 
> #beginContent #pragma 'methodName=dostuff' #pragma 'withThis' super [" 
> was not expected at this position.|




On 7/29/2008 5:04 PM, P T Withington wrote:
> On 2008-07-29, at 10:21EDT, André Bargull wrote:
>
>> Do we want to allow non-literal attribute names for the 
>> "super.setAttribute(..)" call? I'm just thinking about js2-setters 
>> and our (possible) future plans to compile away the 
>> "setAttribute"-mechanism with real js2-setters. I just want to 
>> prevent that users make any non-sense with the 
>> "super.setAttribute"-stuff, so that we may need to provide any scary 
>> backward compatibility thing in the future. At least we should state 
>> that this is not supported and may change in future versions..
>
> Hm.  This is a good point.  We could just make this an error, I don't 
> know if it is used anywhere already.  Although I think in theory you 
> could still do this in JS2 because there is `intrisic::set(id, value)` 
> and I would think you should be able to say:
>
>   super[id] = value;
>
> to invoke a super setter method at runtime.  Although, from your notes 
> below, apparently as3 does not allow this.
>
>> And it's also currently not possible in swf9 at all, see point (iii).
>
> That's too bad.  Possibly a reason for ruling it out.  If this is 
> really not used anywhere in code, I suppose now is as good a time as 
> any to disallow it.
>
>> Next problem I hit: what about "Function#call" and "Function#apply"? 
>> swf8 gave a runtime error, swf9 a compile error. Point (i)
>
> Ouch.  I guess I save myself a lot of trouble if I don't allow any of 
> these crazy things.  Surely this pattern is not used in any existing 
> code.
>
>> And what is the expected behaviour when I attempt to call a 
>> non-existing super-setter? swf9 emits a (native) runtime-error, the 
>> swf8 error was less "informative" (apart from the line number info). 
>> Point (ii)
>
> I think that's the best we can do.  This is no different than calling 
> super in any other case where there is no super method.
>
>> Otherwise approved!
>>
>>
>> (i) using "call" or "apply"
>>> <setter name="foo" args="newfoo">
>>>    Debug.info("sub.set foo: %s", newfoo);
>>>    super.setAttribute.apply(this, ["foo", newfoo]);
>>>    //super.setAttribute.call(this, "foo", newfoo);
>>> </setter>
>> swf8 compilation - runtime error:
>>> ERROR @LPP-5587.lzx#21: undefined object does not have a property 
>>> 'apply'
>> swf9 compilation - compile error:
>>> |LPP-5587.lzx:22:5: Syntax error: the token "[" was not expected at 
>>> this position.
>>> Was expecting one of: (, .|
>>
>>
>> (ii) using "super.setAttribute" without super-setter
>>> <class name="sub" extends="base">
>>>    <attribute name="bar" value="false" type="boolean" />
>>>    <setter name="bar" args="newbar" >
>>>      Debug.info("sub.set bar: %s", newbar);
>>>      super.setAttribute("bar", newbar);
>>>    </setter>
>>>  </class>
>> swf8 compilation - runtime error:
>>> ERROR @LPP-5587.lzx#26: undefined object does not have a property 
>>> 'call'
>> swf9 compilation - runtime error in swf9.
>>> ReferenceError: Error #1070: Method $lzc$set_bar not found in 
>>> .$lzc$class_base
>>
>>
>> (iii) non literal for attribute name:
>>
>>> <class name="sub" extends="base">
>>>    <setter name="foo" args="newfoo">
>>>      Debug.info("sub.set foo: %s", newfoo);
>>>      var methname = "foo";
>>>      super.setAttribute(methname, newfoo);
>>>    </setter>
>>>  </class>
>> swf9 compilation - compile error:
>>> |LPP-5587.lzx:22:5: Syntax error: the token "[" was not expected at 
>>> this position.
>>> Was expecting one of: (, .|
>>
>>
>> On 7/29/2008 1:04 PM, P T Withington wrote:
>>> [REVISED: I really think I got the change set up to date now.]
>>>
>>> Change 20080728-ptw-G by ptw at dueling-banjos.local on 2008-07-28 
>>> 16:57:52 EDT
>>>    in /Users/ptw/OpenLaszlo/dingdong-clean
>>>    for http://svn.openlaszlo.org/openlaszlo/trunk
>>>
>>> Summary: Implement <setter>
>>>
>>> Bugs Fixed:
>>> LPP-5587 'Improve LZX getter/setter to be more like conventional O-O 
>>> languages'
>>>
>>> Technical Reviewer: a.bargull at intensis.de (pending)
>>> QA Reviewer: promanik at laszlosystems.com (pending)
>>>
>>> Release Notes:
>>>    There is a new tag available in classes and instances (<setter>)
>>>    that can be used to define a setter for an attribute.  This tag
>>>    can be used to override a built-in setter.  The overridden setter
>>>    can be invoked by using `super.setAttribute`.
>>>
>>> Details:
>>>    schema: allow <setter> in canvas and node
>>>
>>>    swf9stubs: use LzFormatter for prettier output
>>>
>>>    JavascriptGenerator, CodeGenerator, SWF9Generator: Transform
>>>    `super.setAttribute(x, y)` to `super['$lzc$set_' + x](y)`.
>>>
>>>    NodeModel: Add support or the <setter> tag.
>>>
>>> Tests:
>>>    Test case from bug, in swf8, dhtml, and swf9
>>>
>>> Files:
>>> M      WEB-INF/lps/schema/lfc.lzx
>>> M      WEB-INF/lps/lfc/debugger/swf9stubs.lzs
>>> M      
>>> WEB-INF/lps/server/src/org/openlaszlo/sc/JavascriptGenerator.java
>>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/CommonGenerator.java
>>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/SWF9Generator.java
>>> M      WEB-INF/lps/server/src/org/openlaszlo/compiler/NodeModel.java
>>>
>>> Changeset: 
>>> http://svn.openlaszlo.org/openlaszlo/patches/20080728-ptw-G.tar
>>>
>
>