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 >
