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%7C14f2b02abdf14529768408d57e16e9d4 >>>%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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7C14f2b02abdf14529768408d57e16e9d4 >>>%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63655353 >>>73 >>> >>>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserv >>>ed >>> =0>* >
