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://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Reply via email to