You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/02/27 17:48:56 UTC
Flex Emulation SWCs
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
Re: Flex Emulation SWCs
Posted by Peter Ent <pe...@adobe.com.INVALID>.
My plan is to work through each major component and fill in gaps. For
example, with mx.controls.Button, we can emulate that with TextButton as
the base and add in the few missing pieces (eg, useHandCursor).
We should also create and use tests so that there's a uniform approach to
building these out. I think a lot of current Flex projects can benefit
from the work. Just need to get started. I'm still trying to figure out
how to get the tests we have to run without errors!
‹peter
On 2/28/18, 1:27 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
>
>On 2/28/18, 9:53 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>
>>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.
>
>I'm not sure which would be faster. If it was simple text replacement,
>then just running sed would be faster, but I'm thinking it won't be simple
>text replacement. There might be a "label" property on her MXML
>components that shouldn't be changed to "text". And other MXML tags might
>be replaced by sets of MXML tags and if you don't wrap those up into
>components, then if you decide the replacement set was not right, you have
>to go and find all of the other instances which can be tricky.
>
>Having recently done the rename from FlexJS to Royale, we just recently
>found another problem in the text replacement.
>
>Also, if we come out with a set of emulations, it should make migration
>easier for the next people who try to migrate.
>
>And finally, it allows us to help her migrate without us having to touch
>her 500 MXML files.
>
>If there's a better way, speak up now.
>
>My 2 cents,
>-Alex
>>
>>What do others think ?
>>
>>Thanks, Piotr
>>
>>
>>2018-02-27 20:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>
>>>
>>>
>>> On 2/27/18, 11:18 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>> >>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" <piotrzarzycki21@gmail.com
>>> >><ma...@gmail.com>> 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 <ha...@gmail.com>:
>>> >>>
>>> >>>> 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
>>><ah...@adobe.com.INVALID>
>>> >>>> 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" <ha...@gmail.com> 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
>>><ah...@adobe.com.INVALID>
>>> >>>>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>r
>>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74
>>b
>>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554372
>>1
>>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved=
>>0
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>r
>>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74
>>b
>>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554372
>>1
>>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved=
>>0
>>>*
>
Re: Flex Emulation SWCs
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 2/28/18, 9:53 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>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.
I'm not sure which would be faster. If it was simple text replacement,
then just running sed would be faster, but I'm thinking it won't be simple
text replacement. There might be a "label" property on her MXML
components that shouldn't be changed to "text". And other MXML tags might
be replaced by sets of MXML tags and if you don't wrap those up into
components, then if you decide the replacement set was not right, you have
to go and find all of the other instances which can be tricky.
Having recently done the rename from FlexJS to Royale, we just recently
found another problem in the text replacement.
Also, if we come out with a set of emulations, it should make migration
easier for the next people who try to migrate.
And finally, it allows us to help her migrate without us having to touch
her 500 MXML files.
If there's a better way, speak up now.
My 2 cents,
-Alex
>
>What do others think ?
>
>Thanks, Piotr
>
>
>2018-02-27 20:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>>
>>
>> On 2/27/18, 11:18 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>> >>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" <piotrzarzycki21@gmail.com
>> >><ma...@gmail.com>> 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 <ha...@gmail.com>:
>> >>>
>> >>>> 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 <ah...@adobe.com.INVALID>
>> >>>> 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" <ha...@gmail.com> 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
>><ah...@adobe.com.INVALID>
>> >>>>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74b
>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365543721
>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74b
>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365543721
>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved=0
>>*
Re: Flex Emulation SWCs
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@adobe.com.invalid>:
>
>
> On 2/27/18, 11:18 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> >>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" <piotrzarzycki21@gmail.com
> >><ma...@gmail.com>> 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 <ha...@gmail.com>:
> >>>
> >>>> 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 <ah...@adobe.com.INVALID>
> >>>> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> >>>>>>> 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>*
Re: Flex Emulation SWCs
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 2/27/18, 11:18 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>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" <piotrzarzycki21@gmail.com
>><ma...@gmail.com>> 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 <ha...@gmail.com>:
>>>
>>>> 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 <ah...@adobe.com.INVALID>
>>>> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>>> 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>*
>
Re: Flex Emulation SWCs
Posted by Harbs <ha...@gmail.com>.
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.
> On Feb 27, 2018, at 9:13 PM, Alex Harui <ah...@adobe.com.INVALID> 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" <piotrzarzycki21@gmail.com <ma...@gmail.com>> 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 <ha...@gmail.com>:
>>
>>> 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 <ah...@adobe.com.INVALID>
>>> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>> 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.patr <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr>
>> eon.com <http://eon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%7Ca5c7823f7f7442
>> fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373
>> 61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved
>> =0
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr>
>> eon.com <http://eon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%7Ca5c7823f7f7442
>> fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373
>> 61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved
>> =0>*
Re: Flex Emulation SWCs
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <pi...@gmail.com> 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 <ha...@gmail.com>:
>
>> 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 <ah...@adobe.com.INVALID>
>> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>> >>> 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.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca5c7823f7f7442
>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373
>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved
>=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca5c7823f7f7442
>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373
>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved
>=0>*
Re: Flex Emulation SWCs
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ha...@gmail.com>:
> 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 <ah...@adobe.com.INVALID>
> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> >>> 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>*
Re: Flex Emulation SWCs
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>> 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
>>>
>>
>
Re: Flex Emulation SWCs
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>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
>>
>
Re: Flex Emulation SWCs
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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
>