Re: ArrayCollection in Royale

[Carlos Rovira]

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 :

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

Re: ArrayCollection in Royale

[Alex Harui]

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"
 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 :
>
>> 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" 
>>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 :
>> >
>> >> 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%
>> 

Re: ArrayCollection in Royale

[Alex Harui]

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

[Piotr Zarzycki]

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 :

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