> In Flex, aren't all setters defined as functions that don't return
anything?  I wonder if more complex chained assignments are allowed

Yes, setters must have a return type of void. However, the Flex compiler
allows chained assignments with accessors. I assumed that meant that the
getter was called. However...

> I think in the AS VM, the value 10 is pushed on the stack and left on the
stack after the assignment so it can be assigned to the next thing in the
chain.

I did a quick test of a chained assignment with the Flex compiler and Flash
Player, and I can see the setter being called, but not the getter. The
original value is propagating, though, so I guess it must use the value
from the stack, like you said.

That will require a different approach.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Feb 28, 2022 at 11:46 AM Alex Harui <aha...@adobe.com.invalid>
wrote:

> Interesting.  In Flex, aren't all setters defined as functions that don't
> return anything?  I wonder if more complex chained assignments are allowed:
>
> foo = 1 + bar = 10;
>
> If not (or maybe even if it does work), then maybe it is best to deal with
> this as an assignment pattern and not bother to generate code that returns
> a value which I suspect would be wasteful 99% of the time it isn't used in
> a chain assignment.
>
> I think in the AS VM, the value 10 is pushed on the stack and left on the
> stack after the assignment so it can be assigned to the next thing in the
> chain.
>
> HTH,
> -Alex
>
> On 2/28/22, 10:38 AM, "GitBox" <g...@apache.org> wrote:
>
>
>     joshtynjala commented on issue #210:
>     URL:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fissues%2F210%23issuecomment-1054550835&amp;data=04%7C01%7Caharui%40adobe.com%7C585f7c9bbf31412ddc4e08d9fae993a6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637816703377905729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FS%2FUXUvEuIUtGA3cOABVjsvn2%2FQ3RAFXdjRDQRrV1uc%3D&amp;reserved=0
>
>
>        I suspect this applies to any getter/setter property, and not only
> ones accessed using `super`.
>
>        This seems to be how the JS code is generated:
>
>        ```js
>        this.com_example_MyClass_something =
> com.example.MyClass.superClass_.set__mySetter.apply(this, [ value] );
>        ```
>
>        It fails because the setter doesn't return anything. So I think
> that `undefined` would be assigned to `something`, instead of the value.
>
>        The generated JS should probably be something like this instead:
>
>        ```js
>        com.example.MyClass.superClass_.set__mySetter.apply(this, [ value] )
>        this.com_example_MyClass_something =
> com.example.MyClass.superClass_.get__mySetter.apply(this);
>        ```
>
>        However, I think that will be tricky to generate because I'm pretty
> sure that the emitter writes multiple assignments without looking ahead,
> and `this.com_example_MyClass_something` will already be be emitted before
> we even detect that there's a setter involved.
>
>        It might not look pretty, but I think that we can use the [comma
> operator](
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FReference%2FOperators%2FComma_Operator&amp;data=04%7C01%7Caharui%40adobe.com%7C585f7c9bbf31412ddc4e08d9fae993a6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637816703377905729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=0BqmirUJ8UplBYGscHHaz5Laqp4fWW9VpNJgHGQzgkE%3D&amp;reserved=0)
> to make this work. Probably safest with parentheses around the full
> expression.
>
>        ```js
>        this.com_example_MyClass_something =
> (com.example.MyClass.superClass_.set__mySetter.apply(this, [ value]),
> com.example.MyClass.superClass_.get__mySetter.apply(this));
>        ```
>
>
>     --
>     This is an automated message from the Apache Git Service.
>     To respond to the message, please log on to GitHub and use the
>     URL above to go to the specific comment.
>
>     To unsubscribe, e-mail: issues-unsubscr...@royale.apache.org
>
>     For queries about this service, please contact Infrastructure at:
>     us...@infra.apache.org
>
>
>
>

Reply via email to