Re: ArrayCollection in Royale
Hi Alex, I only expose what I think is better for the project. The same I said for AMF and RemoteObject. If you check today to Royale in twitter, many people asked if we have AMF/RemoteObject support. So as I mentioned, that is key for many people out there. Now thanks to past effort, I can respond in twitter "Hey! Yes we implemented that! Come on check it yourself". With ArrayCollection, I'm telling you all what I think about it. You can said that's not your task, or that is not something needed. This is all subjective. My point is that ArrayCollection will make Royale more successful since people starting to work with Royale, soon will need it, or they will end saying "...no ArrayCollection? oooh..." And will see that they must change all their client communication layer. Something doable, but maybe we can make this less painful for them. About making AC myself, I thinkI'm not the right person for that task. I agree with you that not all components should be done by Adobe people, but I think that's not the point now. We want Royale to be a successfull project, I doesn't mind how task are assigned. I'm more in the UX-front end with website, look and feel, and if have time I'd like to collaborate with docs and reference. If I stop the rest of things to start working on AC, I think this not would be the best decision, since is not where I can make my best work. Honestly. As I already said, for me the first point is to have AC, then how is internally implemented is less important since smart people here can end evolving the internals to make it work blazing fast, I'm sure of that. But name and api can remain constant. Just my 2 2018-02-15 20:46 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > Hi Carlos, > > Looking at the screenshot Alina shared, plus some past discussion, lots of > folks just used the default skins. I don't think they care too much if > the Royale skin looks like Spark or not, but those who disagree should > speak up now. > > s:Button has over 100 APIs. Many of which are inherited from Flash Sprite. > It would take us a long time to replicate everything. On the other hand, > many folks use s:Button in mxml with only a few attributes, and a bunch > more also reference it in their code to dynamically manage the UI. > > ArrayCollection may or may not be that different from s:Button. I've > definitely seen ArrayCollection used in fx:Declaration blocks in MXML. > Seems like a simple search and replace should also work here. If that's > too risky, then it is time to find a volunteer to mimic these classes > using the same package name. But in theory, 99% of your business logic > shouldn't be working off of ResultEvent handlers. The handler should be > calling some entry point in your business logic. > > The key points here is, as I mentioned in the other thread, expectations > and time. You want an org.apache.royale.collections.ArrayCollection? Go > build it. Don't wait for me or Peter. We need to change the mindset that > the components are being created by Adobe. They need to be created by > everybody. You don't even need agreement from others. We've proven that > the tool chain can handle different component sets. Create a component > set or two that reduces the number of lines you have to change when > migrating. > > On the technical issue: In order for ArrayCollection to support array > access in Flash (myAC[0]) ArrayCollection extends Proxy. Array accesses > call a function that has to do a string to int and then access the > internal array. It is much slower than getItemAt. I have implemented > Proxy in JavaScript. It has to make the same slow function call. There > are alternative implementations available for JavaScript if you make > certain assumptions. For example, if there won't be add/remove on the > ArrayCollection, you could prepopulate the index properties on the > instance. Might not be fast for 10,000 rows at conversion time, but > access afterwards would be faster than getItemAt. And there are options > in-between where for add/remove you take the time to repopulate the index > properties. > > That is another reason in Royale we have beads and multiple component > sets. We don't have to choose just one implementation. There might be a > "ReallyFastArrayCollectionForImmutableArrays". And so on. > > My 2 cents, > -Alex > > On 2/15/18, 1:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi Alex, > > > >I assume that UX is very different and although we have a "s:Button" lots > >of changes must be done, so in the end, I think people must rewrite UX. > >But AS3 classes are almost the same (lots of vars type
Re: ArrayCollection in Royale
Hi Carlos, Looking at the screenshot Alina shared, plus some past discussion, lots of folks just used the default skins. I don't think they care too much if the Royale skin looks like Spark or not, but those who disagree should speak up now. s:Button has over 100 APIs. Many of which are inherited from Flash Sprite. It would take us a long time to replicate everything. On the other hand, many folks use s:Button in mxml with only a few attributes, and a bunch more also reference it in their code to dynamically manage the UI. ArrayCollection may or may not be that different from s:Button. I've definitely seen ArrayCollection used in fx:Declaration blocks in MXML. Seems like a simple search and replace should also work here. If that's too risky, then it is time to find a volunteer to mimic these classes using the same package name. But in theory, 99% of your business logic shouldn't be working off of ResultEvent handlers. The handler should be calling some entry point in your business logic. The key points here is, as I mentioned in the other thread, expectations and time. You want an org.apache.royale.collections.ArrayCollection? Go build it. Don't wait for me or Peter. We need to change the mindset that the components are being created by Adobe. They need to be created by everybody. You don't even need agreement from others. We've proven that the tool chain can handle different component sets. Create a component set or two that reduces the number of lines you have to change when migrating. On the technical issue: In order for ArrayCollection to support array access in Flash (myAC[0]) ArrayCollection extends Proxy. Array accesses call a function that has to do a string to int and then access the internal array. It is much slower than getItemAt. I have implemented Proxy in JavaScript. It has to make the same slow function call. There are alternative implementations available for JavaScript if you make certain assumptions. For example, if there won't be add/remove on the ArrayCollection, you could prepopulate the index properties on the instance. Might not be fast for 10,000 rows at conversion time, but access afterwards would be faster than getItemAt. And there are options in-between where for add/remove you take the time to repopulate the index properties. That is another reason in Royale we have beads and multiple component sets. We don't have to choose just one implementation. There might be a "ReallyFastArrayCollectionForImmutableArrays". And so on. My 2 cents, -Alex On 2/15/18, 1:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: >Hi Alex, > >I assume that UX is very different and although we have a "s:Button" lots >of changes must be done, so in the end, I think people must rewrite UX. >But AS3 classes are almost the same (lots of vars type String, Number, >int, >Boolean,and ArrayCollection). In this point, it will be a shame to >make >people to go each file making changes to get ArrayCollections to match >other classes methods and signatures... > >In the other hand, about internals of how ArrayCollection operates, I >think >that can be reworked in order to perform better, right? > > > >2018-02-15 9:20 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > >> If the goal is to further reduce the number of changes to migrated code, >> we should just start a new component set. IIRC, ArrayCollection usually >> has very bad performance if you use array indexing to access it. >> ArrayList should perform much better but you can't use array indexing. >> Filtering and sorting should be written as beads. >> >> My 2 cents, >> -Alex >> >> On 2/15/18, 12:11 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> >>wrote: >> >> >Hi Carlos, >> > >> >We have ArrayList which is enough close to ArrayCollection. I have with >> >success replace ArrayCollection to ArrayList in my examples. >> > >> >Thanks, Piotr >> > >> >2018-02-15 8:47 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: >> > >> >> Hi >> >> >> >> I saw Alina post in user list about substitutes and I think one >> >>important >> >> one is: >> >> >> >> import mx.collections.ArrayCollection; //very similar to >> >> org.apache.royale.collections.TreeData >> >> >> >> In order to ease the port of Flex apps to Royale, one thing we try >>is to >> >> reuse as much AS3 logic, while in UX we need to create all new code >> >> >> >> ArrayCollection is very close to business logic, and widely used in >>AMF >> >>
Re: ArrayCollection in Royale
If the goal is to further reduce the number of changes to migrated code, we should just start a new component set. IIRC, ArrayCollection usually has very bad performance if you use array indexing to access it. ArrayList should perform much better but you can't use array indexing. Filtering and sorting should be written as beads. My 2 cents, -Alex On 2/15/18, 12:11 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote: >Hi Carlos, > >We have ArrayList which is enough close to ArrayCollection. I have with >success replace ArrayCollection to ArrayList in my examples. > >Thanks, Piotr > >2018-02-15 8:47 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > >> Hi >> >> I saw Alina post in user list about substitutes and I think one >>important >> one is: >> >> import mx.collections.ArrayCollection; //very similar to >> org.apache.royale.collections.TreeData >> >> In order to ease the port of Flex apps to Royale, one thing we try is to >> reuse as much AS3 logic, while in UX we need to create all new code >> >> ArrayCollection is very close to business logic, and widely used in AMF >> calls. >> >> I suggest we should have ArrayCollection in Royale and even respect >> namespace to avoid users to change any line in AS3 code. >> >> Only with this point we can remove lots of pain in migration process >>from >> Flex to Royale >> >> what do you think? >> >> -- >> Carlos Rovira >> >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% >>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C10ecbb5b8c464b4ed36708 >>d5744bcadb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654279123032447 >>4=RY6LraL22n2Yt9QiNyJc0FQms64yALaKy16%2FNW7XHJc%3D=0 >> > > > >-- > >Piotr Zarzycki > >Patreon: >*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C10ecbb5b8c464b >4ed36708d5744bcadb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365427912 >30324474=mwO%2FFFYUAHHA8VlHeJQreNzUOMKzd%2BeqaMV6%2FNPhIKk%3D >ed=0 ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C10ecbb5b8c464b >4ed36708d5744bcadb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365427912 >30324474=mwO%2FFFYUAHHA8VlHeJQreNzUOMKzd%2BeqaMV6%2FNPhIKk%3D >ed=0>*
Re: ArrayCollection in Royale
Hi Carlos, We have ArrayList which is enough close to ArrayCollection. I have with success replace ArrayCollection to ArrayList in my examples. Thanks, Piotr 2018-02-15 8:47 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > Hi > > I saw Alina post in user list about substitutes and I think one important > one is: > > import mx.collections.ArrayCollection; //very similar to > org.apache.royale.collections.TreeData > > In order to ease the port of Flex apps to Royale, one thing we try is to > reuse as much AS3 logic, while in UX we need to create all new code > > ArrayCollection is very close to business logic, and widely used in AMF > calls. > > I suggest we should have ArrayCollection in Royale and even respect > namespace to avoid users to change any line in AS3 code. > > Only with this point we can remove lots of pain in migration process from > Flex to Royale > > what do you think? > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
ArrayCollection in Royale
Hi I saw Alina post in user list about substitutes and I think one important one is: import mx.collections.ArrayCollection; //very similar to org.apache.royale.collections.TreeData In order to ease the port of Flex apps to Royale, one thing we try is to reuse as much AS3 logic, while in UX we need to create all new code ArrayCollection is very close to business logic, and widely used in AMF calls. I suggest we should have ArrayCollection in Royale and even respect namespace to avoid users to change any line in AS3 code. Only with this point we can remove lots of pain in migration process from Flex to Royale what do you think? -- Carlos Rovira http://about.me/carlosrovira