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 >> >
