Hi Alex, thanks for the explanation.
regarding integration branches, the main concept it *not break develop* (and of course master ;)). So before Harbs response, I was worried that this merge could cause some days of broken builds (maven, ant, etc...) for that reason is important to make this kind of laborious merges a side the branches so when you have it running nice in your local you could merge with original branch with no effort and secure that all would be ok. That's the main purpose of doing anything you want in branches. More over, is normal for all people working in projects with GIt and using JIRA or other system, to open a branch per ticket so you can solve the ticket and merge it back to develop, and then remove the ticket branch. So I think Harbs and you are managing in other way, as Harbs is integrating changes from develop as they happen so deltas are controlled and the branch is never to far from develop state. Regarding the refactor, I can see the points here, but have not opinion (as I said I'd need to check code of the work done) at this point so I'm confident you both will do the best Thanks 2016-10-27 18:26 GMT+02:00 Alex Harui <aha...@adobe.com>: > > > 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 > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
