[FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Alex Harui <ah...@adobe.com>]

Hi,

I just pushed changes to allow certain kinds of overrides in SWF that
normally aren't possible.  The reasoning behind doing this is to allow us
to have a library that extends SWF classes like Sprite but hide the flash
APIs.

For example, in Sprite, the parent property is defined as a
flash.display.DisplayObjectContainer.  In FlexJS, we would much rather use
a non-Flash API like org.apache.flex.core.IParent, so a parent can be
platform-agnostic.  Similarly, the dispatchEvent API takes a
flash.events.Event and it would be better to have it take an
org.apache.flex.events.Event, or maybe an
org.apache.flex.events.IFlexJSEvent.

So, in our base classes, we would want to write:

   override public function get parent():IParent

And

   override public function
dispatchEvent(event:org.apache.flex.events.Event):Boolean

But not only would the SWF compiler not allow that, the Flash runtime
checks the type of any override at runtime and reports an error if there
isn't a match (and such an issue would not be caught by the JS runtime).

So to get this all to work, the compiler needs to know that certain
type-mismatches are allowed, and also to restore the type to the original
type in the SWF.  To do so, I taught the compiler to look for a
SWFOverride metadata that provides the original types for parameters or
return values.  When the compiler sees a mismatch, it checks for metadata
allowing the mismatch.  And when writing out the SWF, it also checks for
the metadata and replaces the types in the ABC traits.  So far, in minimal
testing, it seems to work.

Next up, after fixing a bunch of bugs in the queue, is to work on having
the compiler generate both SWF and JS output in a single run.  Then with
proper overriding of various Flash APIs, we should be able to provide a
more efficient way for FlexJS developers to see any conflicts with
underlying platform implementations without having to wrap every
implementation.

Later,
-Alex

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Alex Harui <ah...@adobe.com>]

On 12/6/16, 8:36 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>I did a quick test the other day where I tried creating a
>flexjs-config.xml, which used js.swc instead of playerglobal.swc and the
>SWCs in frameworks/js/FlexJS/libs instead of frameworks/libs. When I used
>this new config, it didn't show any Flash APIs in the completion list in
>VSCode, which was better. I don't recall if I had time to test if the
>project would build correctly or not, though. A workflow like this could
>help for people only interested in JS output. It would expose APIs that
>aren't available in SWFs, though, so it's not removing the problem, but
>simply reversing it.

True.

I understand the temptation to claim that if FlexJS isn't as easy to work
with as Flex that we won't succeed, and we want to make the experience as
smooth as possible, but consider that this is still not even a 1.0
product, and that customers are faced with dealing with a few bumps in our
road, or doing a full port to another JS framework.

We are introducing something new: multi-target, multi-platform output.
Such a workflow simply may not be as smooth as a single-target workflow.
Well, we could wrap everything and so there is only one common API, but in
my experience, folks will always point at the additional overhead and
wonder how much better it would work without that overhead.  Many of you
are familiar with this to some degree.  You see your mobile app work on
your laptop, then you try to publish it out to Android or IOS and it
doesn't work or is too big.

As I mentioned upthread, the next step is to be able to have a single
compiler run output more than one target.  Getting this to work is also
key because it enables us to create a set of SWCs with the common API and
no platform-specific APIs and, while the results of that won't run at all,
it will report compile errors on non-common APIs and then output valid
targets that do run.

Or, folks will just learn to live with the fact that the code hinting in
Flash Builder might show something that doesn't exist on a target
platform, but the compile step will report errors when compiling for the
target without those APIs.  You pick one starting target platform, get
code-hinting for it, then find out at compile time that some of it won't
work on one of the targets.  Right now you have to run a different compile
or another whole project.  After the next set of changes, it should all
show up in the problems list.

But the new IDEs have an opportunity to win customers by enhancing
code-hinting to show what APIs exist on certain platforms.  Also, some
folks may need to "cheat" and write platform-specific code inside
conditional compile blocks in order to be successful.  They should have
code-hinting for platform-specific APIs if they want it.  So it probably
isn't true that all app devs won't want to see platform APIs.

The current IDEs seem to only give us control over code-hinting via code
in SWCs.  New IDEs could be smarter and work with metadata, ASDoc comment
tags, etc.

In sum, perfection is a great goal, but we have to find a minimally-viable
1.0 that isn't perfect, so think about what trade-offs are acceptable.
But I think after the next compiler change, we will have the option of
making different kinds of SWCs to hide APIs.  Combining that with this
change that allows us to change the type of APIs, that should get us
pretty far.  Of course, there might be pain in managing the different
types of SWC combinations, so that is a trade-off to consider.

One more note:  I believe we have control over the ASDoc that is part of
FB code-hinting, so we might be able to document what platform an API
works if we decide that we can't or don't want to hide certain APIs.

My 2 cents,
-Alex

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Josh Tynjala <jo...@gmail.com>]

I did a quick test the other day where I tried creating a
flexjs-config.xml, which used js.swc instead of playerglobal.swc and the
SWCs in frameworks/js/FlexJS/libs instead of frameworks/libs. When I used
this new config, it didn't show any Flash APIs in the completion list in
VSCode, which was better. I don't recall if I had time to test if the
project would build correctly or not, though. A workflow like this could
help for people only interested in JS output. It would expose APIs that
aren't available in SWFs, though, so it's not removing the problem, but
simply reversing it.

- Josh

On Tue, Dec 6, 2016 at 8:25 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 12/6/16, 8:06 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >It's a really big issue that all the Flash display list APIs show up in
> >the
> >completion list for FlexJS components. People are going to get extremely
> >(EXTREMELY!) frustrated that they can't tell at a glance which subset of
> >properties is available in JS or not.
>
> Agreed that the code completion list is important, but not agreed that
> Flash Builder's code completion list is important.
>
> FWIW, this compiler change further cements the gap between application
> developers and framework developers.  The goal of the framework developers
> is to provide the application developers with a platform-agnostic API.
> The person writing the framework code, however, probably should be offered
> Sprite.graphics since he/she is allowed to write to it.  Then we want to
> hide that from the application developer.
>
> It would be great if we can solve that for Flash Builder, but IMO, if
> Flash Builder is make-or-break for Apache FlexJS, we are in big trouble
> since it is a legacy product.  My priority is in the new IDEs that have
> active development such as Moonshine, VS Code, FDT, and maybe others.
>
> We might be able to solve this for Flash Builder simply by changing what
> SWCs go into the application project.  I haven't had time to down this
> road yet, and volunteers are welcome to help out, but the question is,
> what if we replace playerglobal.swc with FlexJSPlayerGlobal.swc that we
> write with just the supported APIs?  Will FB and other IDEs freak out?
>
> Fundamentally, though, this compiler change proved that I can put code in
> a SWC to present a different API than what Flash expects and then muck
> with the ABC code when linking the SWF to create the code that Flash
> expects.  That's pretty powerful.
>
> Thanks,
> -Alex
>
> >
> >- Josh
> >
> >On Tue, Dec 6, 2016 at 1:12 AM, yishayw <yi...@hotmail.com> wrote:
> >
> >> Suppose I have a component A that extends UIBase which extends Sprite.
> >> Suppose I have this code:
> >>
> >> var a:A = new A();
> >>
> >> Suppose I type a.gr ctrl-space.
> >>
> >> Will Flash Builder suggest to complete it to a.graphics even though it
> >>will
> >> result in a compile-time error?
> >>
> >>
> >>
> >> --
> >> View this message in context: http://apache-flex-
> >> development.2333347.n4.nabble.com/FALCONJX-FLEXJS-SWF-
> >> Subclass-and-other-Overrides-tp57008p57030.html
> >> Sent from the Apache Flex Development mailing list archive at
> >>Nabble.com.
> >>
>
>

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Alex Harui <ah...@adobe.com>]

On 12/6/16, 8:06 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>It's a really big issue that all the Flash display list APIs show up in
>the
>completion list for FlexJS components. People are going to get extremely
>(EXTREMELY!) frustrated that they can't tell at a glance which subset of
>properties is available in JS or not.

Agreed that the code completion list is important, but not agreed that
Flash Builder's code completion list is important.

FWIW, this compiler change further cements the gap between application
developers and framework developers.  The goal of the framework developers
is to provide the application developers with a platform-agnostic API.
The person writing the framework code, however, probably should be offered
Sprite.graphics since he/she is allowed to write to it.  Then we want to
hide that from the application developer.

It would be great if we can solve that for Flash Builder, but IMO, if
Flash Builder is make-or-break for Apache FlexJS, we are in big trouble
since it is a legacy product.  My priority is in the new IDEs that have
active development such as Moonshine, VS Code, FDT, and maybe others.

We might be able to solve this for Flash Builder simply by changing what
SWCs go into the application project.  I haven't had time to down this
road yet, and volunteers are welcome to help out, but the question is,
what if we replace playerglobal.swc with FlexJSPlayerGlobal.swc that we
write with just the supported APIs?  Will FB and other IDEs freak out?

Fundamentally, though, this compiler change proved that I can put code in
a SWC to present a different API than what Flash expects and then muck
with the ABC code when linking the SWF to create the code that Flash
expects.  That's pretty powerful.

Thanks,
-Alex

>
>- Josh
>
>On Tue, Dec 6, 2016 at 1:12 AM, yishayw <yi...@hotmail.com> wrote:
>
>> Suppose I have a component A that extends UIBase which extends Sprite.
>> Suppose I have this code:
>>
>> var a:A = new A();
>>
>> Suppose I type a.gr ctrl-space.
>>
>> Will Flash Builder suggest to complete it to a.graphics even though it
>>will
>> result in a compile-time error?
>>
>>
>>
>> --
>> View this message in context: http://apache-flex-
>> development.2333347.n4.nabble.com/FALCONJX-FLEXJS-SWF-
>> Subclass-and-other-Overrides-tp57008p57030.html
>> Sent from the Apache Flex Development mailing list archive at
>>Nabble.com.
>>

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Josh Tynjala <jo...@gmail.com>]

It's a really big issue that all the Flash display list APIs show up in the
completion list for FlexJS components. People are going to get extremely
(EXTREMELY!) frustrated that they can't tell at a glance which subset of
properties is available in JS or not.

- Josh

On Tue, Dec 6, 2016 at 1:12 AM, yishayw <yi...@hotmail.com> wrote:

> Suppose I have a component A that extends UIBase which extends Sprite.
> Suppose I have this code:
>
> var a:A = new A();
>
> Suppose I type a.gr ctrl-space.
>
> Will Flash Builder suggest to complete it to a.graphics even though it will
> result in a compile-time error?
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FALCONJX-FLEXJS-SWF-
> Subclass-and-other-Overrides-tp57008p57030.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[yishayw <yi...@hotmail.com>]

Suppose I have a component A that extends UIBase which extends Sprite.
Suppose I have this code:

var a:A = new A();

Suppose I type a.gr ctrl-space.

Will Flash Builder suggest to complete it to a.graphics even though it will
result in a compile-time error?



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FALCONJX-FLEXJS-SWF-Subclass-and-other-Overrides-tp57008p57030.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Alex Harui <ah...@adobe.com>]

On 12/5/16, 11:41 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:

>Sounds good.
>
>
>
>Will you be addressing code-hinting issues?

Can you be more specific about which issues you are referring to?

-Alex

RE: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Yishay Weiss <yi...@hotmail.com>]

Sounds good.



Will you be addressing code-hinting issues?



From: Alex Harui<ma...@adobe.com>
Sent: Monday, December 5, 2016 8:50 PM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides



Hi,

I just pushed changes to allow certain kinds of overrides in SWF that
normally aren't possible.  The reasoning behind doing this is to allow us
to have a library that extends SWF classes like Sprite but hide the flash
APIs.

For example, in Sprite, the parent property is defined as a
flash.display.DisplayObjectContainer.  In FlexJS, we would much rather use
a non-Flash API like org.apache.flex.core.IParent, so a parent can be
platform-agnostic.  Similarly, the dispatchEvent API takes a
flash.events.Event and it would be better to have it take an
org.apache.flex.events.Event, or maybe an
org.apache.flex.events.IFlexJSEvent.

So, in our base classes, we would want to write:

   override public function get parent():IParent

And

   override public function
dispatchEvent(event:org.apache.flex.events.Event):Boolean

But not only would the SWF compiler not allow that, the Flash runtime
checks the type of any override at runtime and reports an error if there
isn't a match (and such an issue would not be caught by the JS runtime).

So to get this all to work, the compiler needs to know that certain
type-mismatches are allowed, and also to restore the type to the original
type in the SWF.  To do so, I taught the compiler to look for a
SWFOverride metadata that provides the original types for parameters or
return values.  When the compiler sees a mismatch, it checks for metadata
allowing the mismatch.  And when writing out the SWF, it also checks for
the metadata and replaces the types in the ABC traits.  So far, in minimal
testing, it seems to work.

Next up, after fixing a bunch of bugs in the queue, is to work on having
the compiler generate both SWF and JS output in a single run.  Then with
proper overriding of various Flash APIs, we should be able to provide a
more efficient way for FlexJS developers to see any conflicts with
underlying platform implementations without having to wrap every
implementation.

Later,
-Alex

Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides

[Harbs <ha...@gmail.com>]

I like.

On Dec 5, 2016, at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:

> Hi,
> 
> I just pushed changes to allow certain kinds of overrides in SWF that
> normally aren't possible.  The reasoning behind doing this is to allow us
> to have a library that extends SWF classes like Sprite but hide the flash
> APIs.
> 
> For example, in Sprite, the parent property is defined as a
> flash.display.DisplayObjectContainer.  In FlexJS, we would much rather use
> a non-Flash API like org.apache.flex.core.IParent, so a parent can be
> platform-agnostic.  Similarly, the dispatchEvent API takes a
> flash.events.Event and it would be better to have it take an
> org.apache.flex.events.Event, or maybe an
> org.apache.flex.events.IFlexJSEvent.
> 
> So, in our base classes, we would want to write:
> 
>   override public function get parent():IParent
> 
> And
> 
>   override public function
> dispatchEvent(event:org.apache.flex.events.Event):Boolean
> 
> But not only would the SWF compiler not allow that, the Flash runtime
> checks the type of any override at runtime and reports an error if there
> isn't a match (and such an issue would not be caught by the JS runtime).
> 
> So to get this all to work, the compiler needs to know that certain
> type-mismatches are allowed, and also to restore the type to the original
> type in the SWF.  To do so, I taught the compiler to look for a
> SWFOverride metadata that provides the original types for parameters or
> return values.  When the compiler sees a mismatch, it checks for metadata
> allowing the mismatch.  And when writing out the SWF, it also checks for
> the metadata and replaces the types in the ABC traits.  So far, in minimal
> testing, it seems to work.
> 
> Next up, after fixing a bunch of bugs in the queue, is to work on having
> the compiler generate both SWF and JS output in a single run.  Then with
> proper overriding of various Flash APIs, we should be able to provide a
> more efficient way for FlexJS developers to see any conflicts with
> underlying platform implementations without having to wrap every
> implementation.
> 
> Later,
> -Alex
>