On 10/27/16, 12:56 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>Hi, > >don't know how you plan to do this, but seems an important refactor and >lots of files included. >I suggest to do this in an "integration" branch to manage all posible >colateral issues generated. And then as adjusted merge with develop. I thought about having a separate branch, but didn't do it (yet). How does having an integration branch help? Seems like it would just mean two merges instead of one. I already have other working copies of flex-asjs on my computer so I can handle other requests for changes while the merge is in progress. > >As well, I came to the discussion too much late so I don't know about the >basic thinking of this refactor. Could you share what's behind? (now that >you discuss it for long time) I saw Harbs summed it up, but my take is this: I am a code minimalist, so I am hopeful that we can implement some sort of overloading in the compiler such that we can make it look like we have nice clean no-flash API signature in the FlexJS APIs. IMO, we have to provide some sort of overloading some day anyway since otherwise, ActionScript will fall behind other languages that do support overloading. I believe if we can allow overloading, then you don't need pay the runtime cost of wrapping the platform implementations. You can just make sure the subclasses of the platform implementations have a common API. That means that app developers may trip over the platform implementations more often, but you will be glad we offered you this option if your app becomes too big or too slow. IMO, it is just more efficient to talk to someone who has a different native language but understands enough English (the common API) than to have to use another person as a translator (which effectively wraps the person you want to talk to). But yes, you have to be careful in your choice of words (adding new APIs or using old Flash APIs) since those words might have meaning to the non-English speaker. (I was working with folks from Japan once and mentioned how I liked Tacos for lunch. They were surprised at first because Tako means Octopus in Japanese which isn't nearly as well liked). Here are some scenarios: If you are porting existing Flash-based code to FlexJS, you want to get a good idea of how many changes you have to make. At the time Harbs started on the port, the workflow was to look for "import flash" in your code and replace those imports with FlexJS imports (if they existed) and then just try compiling against the FlexJS SWCs for SWF, since compiling a SWF is what the IDE knows how to do. The problem with that is that a simple reference to, for example, the "scaleX" property is not caught by this workflow. Clearly, if you take the time to create wrappers for the components that only implement the FlexJS APIs that work on both platforms, then the compiler would catch that you are using "scaleX". But we are looking into upgrading the compiler so that you can run the JS cross-compile directly as well as the SWF compile from the IDE, so the problems panel should show that "scaleX" is missing in the cross-compile, and then you don't need to wrap. Similarly, if someday someone wanted to implement a "buttonMode" property on a Button and didn't know the Flash implementation already used it, you will get an error and have to use a different property name. You wouldn't if you are working against wrapped components. Really, there is no right or wrong way. I am just certain that we "must" have a component set that does not have any extra code spent on wrapping implementations if we can implement overloading propertly, or on parameter validation, or anything else you don't need in production. It is totally fine to have other component sets that wrap things, aggregate beads, etc to make development or migration easier, but the low-level must truly be low-level if you are trying to fit your production version into some metric of code size, download size, startup time performance. The framework should not be to blame if you can't fit. The smaller and faster we make it, the better off our customers will be. Even an additional line of code adds up over time. HTH, -Alex
