Alex, I saw your response to Alina about writing emulation and contributing. However how does actually she meet with her deadlines ? To me it sounds like a lot of work, even if you and Peter help. How does emulations speed up the work ?
Does rewriting one by one views won't be simply faster. What do others think ? Thanks, Piotr 2018-02-27 20:52 GMT+01:00 Alex Harui <[email protected]>: > > > On 2/27/18, 11:18 AM, "Harbs" <[email protected]> wrote: > > >Gotcha. > > > >I’m not 100% convinced that it’s going to ultimately be easier like this, > >but it might be interesting to have a migration set and see how useful it > >actually is. > > Yeah, I can't guarantee it will be better, but having recently survived a > huge search and replace to rename FlexJS to Royale, which included a > mistake only found a few days ago, this seems worth a try. > > Later, > -Alex > > > >> On Feb 27, 2018, at 9:13 PM, Alex Harui <[email protected]> > >>wrote: > >> > >> If we put trace statements in the API stubs, the user could get some > >> output that tells what is missing. Or scan the JS for some jsdoc key we > >> leave in the code. But if it compiles, the user will know also what is > >> missing because the App will not look right or operate correctly. > >> > >> Harbs, back when you migrated your app, there was no > >> spark.components.Button and we weren't sure we would ever build one, > >>since > >> a complete implementation requires over 100 methods and properties. I'm > >> still not clear on exactly what steps you took to migrate, so, I am > >> imagining that for every s:Button or "import spark.components.Button" > >>you > >> had to search and replace it with js:TextButton or "import > >> org.apache.royale.html.TextButton". So I'm guessing that you created a > >> spark.components.Button class that was all stubs so the app would > >>compile > >> without having to convert every using of Spark Button, yet it would help > >> you find the remaining places to convert. > >> > >> I am proposing that we actually add an operational > >>spark.components.Button > >> in a SWC that only implements the 12 out of the 100+ APIs that Alina > >> needs. Then there are fewer places to change in her code. The final > >> output will be bigger because we have this additional emulation code, > >>but > >> it should get it up and running. So, the migration experience will be > >> quite different for Alina. You had to do a lot of search and replace > >>with > >> bundles of beads. We are going to encapsulate that work under the API > >> surface. Maybe we don't need to have every migration user do that much > >> searching and replacing. Our goal is to try to encapsulate and > >>eliminate > >> repetitive work where we can. > >> > >> As other users try to migrate, we'll get their API reports, see what is > >> missing and hopefully only need to add a few more APIs. > >> > >> Thoughts? > >> -Alex > >> > >> On 2/27/18, 10:42 AM, "Piotr Zarzycki" <[email protected] > >><mailto:[email protected]>> wrote: > >> > >>> What would be the results for Alina if you will have that swc ? She > >>>simply > >>> will be able to launch application without the error - That's the idea > >>>? > >>> > >>> 2018-02-27 19:38 GMT+01:00 Harbs <[email protected]>: > >>> > >>>> Maybe. Not sure. > >>>> > >>>> How does the client know what needs to be implemented and how do they > >>>>go > >>>> about implementing that? > >>>> > >>>>> On Feb 27, 2018, at 8:32 PM, Alex Harui <[email protected]> > >>>> wrote: > >>>>> > >>>>> Hmm, maybe I'm not understanding you. If we decide to create a SWC > >>>> with > >>>> a > >>>>> spark.components.Button and Alina needs 12 APIs and we only have time > >>>>> right now to implement 6 of them, how would you handle the missing 6? > >>>>> > >>>>> I would just implement those APIs but they wouldn't do anything. > >>>>>They > >>>>> would contain a comment or trace statement or todo. I don't think I > >>>> would > >>>>> create a dummy/stub spark.components.Button class, just dummy/stub > >>>> methods > >>>>> and properties. > >>>>> > >>>>> Maybe we are saying the same thing? > >>>>> -Alex > >>>>> > >>>>> On 2/27/18, 10:15 AM, "Harbs" <[email protected]> wrote: > >>>>> > >>>>>> If things are no-op or to-dos wouldn’t “stubs” or “dummy” classes be > >>>>>> better? > >>>>>> > >>>>>> What’s the advantage of having partially functional SWCs? It seems > >>>> to me > >>>>>> like it would mask the issues? > >>>>>> > >>>>>> Harbs > >>>>>> > >>>>>>> On Feb 27, 2018, at 7:48 PM, Alex Harui <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On the users list, Alina has provided the API report for the main > >>>>>>> portion > >>>>>>> of her application. We are still waiting to get a report on her > >>>>>>>SWC > >>>>>>> library. She might have a pile of modules to report on as well. > >>>>>>> > >>>>>>> Based just on the main application, and her saying that she has 500 > >>>> MXML > >>>>>>> files to port, I'm leaning towards creating migration SWCs that > >>>> reduce > >>>>>>> the > >>>>>>> amount of copy/paste. In her data, we see that only 12 out of more > >>>> than > >>>>>>> 100 APIs on s:Button are being used, and we have 6 of them > >>>> implemented > >>>>>>> already. The plan would be to write the remaining six. Some, like > >>>>>>> useHandCursor might be temporary no-ops or to-dos. > >>>>>>> > >>>>>>> I've been pondering what to name these libraries. I've been using > >>>>>>> MXish.SWC and Sparkish.SWC, but maybe we want a better name like > >>>>>>> MXMigration.SWC/SparkMigration.SWC or MXRoyale.SWC/SparkRoyale.SWC > >>>> or > >>>>>>> RoyaleMX/RoyaleSpark.SWC. I want to imply that it isn't fully > >>>> backward > >>>>>>> compatible in the name of the SWC if possible. > >>>>>>> > >>>>>>> We could leave the namespace URI as > >>>>>>> > >>>>>>> xmlns:s="library://ns.adobe.com/flex/spark" > >>>>>>> xmlns:mx="library://ns.adobe.com/flex/mx" > >>>>>>> > >>>>>>> > >>>>>>> just to have one less thing to change in each MXML file, although > >>>>>>>it > >>>>>>> might > >>>>>>> be better to use a different namespace URI to get "adobe.com" out > >>>>>>>of > >>>>>>> there > >>>>>>> which might help imply that it isn't fully backward compatible and > >>>> go > >>>>>>> with: > >>>>>>> > >>>>>>> xmlns:s="library://ns.apache.org/royale/spark" > >>>>>>> xmlns:mx="library://ns.apache.org/royale/mx" > >>>>>>> > >>>>>>> I don't think we'd bother to fully re-create the Flex class > >>>> hierarchy > >>>> at > >>>>>>> this time, but I think we will need to create a UIComponent that > >>>>>>> subclasses UIBase and have all migration components extend that > >>>> instead > >>>>>>> of > >>>>>>> extending Express or Basic components because we need to change the > >>>> way > >>>>>>> percentWidth/Height work in the migration components. UIBase sets > >>>> the > >>>>>>> style.width to a % value, but we don't want that in the migration > >>>>>>> components. The Flex layout classes use percentage differently. > >>>> The > >>>>>>> cool > >>>>>>> thing is that if we wrote our beads correctly, we can re-compose > >>>>>>>the > >>>>>>> functionality from Basic and Express onto this migration library > >>>> and it > >>>>>>> will "just work". This illustrates the value of composition over > >>>>>>> subclassing. > >>>>>>> > >>>>>>> > >>>>>>> I think it will be a few more days before we have all of the data > >>>> from > >>>>>>> Alina and know how big this task will be so now is a good time to > >>>>>>> discuss > >>>>>>> some of the details on how this would work. > >>>>>>> > >>>>>>> Thoughts? > >>>>>>> -Alex > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> > >>> Piotr Zarzycki > >>> > >>> Patreon: > >>> > >>>*https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.pa > >>>tr > >>><https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.pa > >>>tr> > >>> eon.com > >>><https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Feon.com > >>>%2F&data=02%7C01%7Caharui%40adobe.com%7C14f2b02abdf14529768408d57e16 > e9d4 > >>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636553559236362115&sdata=m > >>>QT%2FmxbQYihs5OxQSivxPFhsngBEIR3dV6%2Bl7ysUp1o%3D&reserved=0>% > 2Fpiotrzar > >>>zycki&data=02%7C01%7Caharui%40adobe.com > >>><https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2F40adobe > >>>.com%2F&data=02%7C01%7Caharui%40adobe.com% > 7C14f2b02abdf14529768408d57e16 > >>>e9d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636553559236362115&sda > >>>ta=3aLPLQZnepcRuNWiYlf8qg%2B1UpNb0DoMfQHnMH%2FvL5w%3D& > reserved=0>%7Ca5c7 > >>>823f7f7442 > >>> > >>>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C63655353 > >>>73 > >>> > >>>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw > %3D&reserv > >>>ed > >>> =0 > >>> > >>><https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.pa > >>>tr > >>><https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.pa > >>>tr> > >>> eon.com > >>><https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Feon.com > >>>%2F&data=02%7C01%7Caharui%40adobe.com%7C14f2b02abdf14529768408d57e16 > e9d4 > >>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636553559236362115&sdata=m > >>>QT%2FmxbQYihs5OxQSivxPFhsngBEIR3dV6%2Bl7ysUp1o%3D&reserved=0>% > 2Fpiotrzar > >>>zycki&data=02%7C01%7Caharui%40adobe.com > >>><https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2F40adobe > >>>.com%2F&data=02%7C01%7Caharui%40adobe.com% > 7C14f2b02abdf14529768408d57e16 > >>>e9d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636553559236362115&sda > >>>ta=3aLPLQZnepcRuNWiYlf8qg%2B1UpNb0DoMfQHnMH%2FvL5w%3D& > reserved=0>%7Ca5c7 > >>>823f7f7442 > >>> > >>>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C63655353 > >>>73 > >>> > >>>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw > %3D&reserv > >>>ed > >>> =0>* > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
