2018-02-15 18:16 GMT+01:00 Alex Harui <aha...@adobe.com>:
> For me, the factors are related to expectations and time. If Royale has
> an mx.collections.ArrayCollection class, will you expect it to be 100%
> compatible and what will you think if it isn't? Or has poor performance?
No, having similar API and similar behaviour will be sufficient. In the end
Royale is not Flex and all we do to get a better implementation while
maintain the way is used I think it will be ok for people trying to migrate.
> So if we say you must search and replace all instances of
> mx.collections.ArrayCollection with
> does that change your expectations about backward compatibility? Is that
> too much to ask folks migrating apps?
What I have in mind is the most easy way to migrate. This implies *not
touch backend never*. In this way actual Flex apps can still work without
touch Flex and backend code (Java, Php .NET... whatever it could be).
People will only need to recreate the client part hosting it *side by side*
with the flex client.
Then when royale version will be enough robust they can remove flex version
and make royale one the official client.
that would be the *dream scenario"
so for that reason I think namespaces should be the same, but we could have
the new royale namespace for new projects, and keep the old one for
migration purposes. That would be only in classes very near to manage
server side communications and business logic
> And if that's ok, what about searching and replacing
> mx.collections.ArrayCollection with org.apache.royale.collections.
I think that will end with the need to change backend code. this will
defeat the purpose of a good migration since you need to separate backends
for actual flex and new royale clients. So not good :(
> We can add more stuff in subclasses of ArrayList to approach
> memory if you try to toss out the ArrayCollection but not its internal
> IList. I would rather set expectations that things are different enough
> that you will have some work to do.
Alex, I'm not an expert in this kind of Arquitecture/implementation, but I
want to believe that with a concrete namespace and class names, functions
and properties, some implementation could be done in js that can perform
and work flawlessly. don't you think?
> Then after we decide how to set expectations, there is the issue of
> finding the time to make components that more closely match Flex. We have
> ArrayList. Who will work on ArrayCollection and sorting? The more folks
> can pitch in, the easier we can make migration, although it will never be
> If you want ResultEvent/FaultEvent, go create it. It should be easy
> enough to do. We don't have to all agree.
Hi, as I said before, I think I'm not the right person for this, I think I
can provide more value in my actual task. If not I'll go that path ;)
Hope someone could take it on his plate ;)
> My 2 cents,