I'm sure many people would be happier if there were fewer lines of code to be 
touched.  IMO, this debate is about where it is reasonable to ask folks to 
change their code.  I am not afraid to ask someone to tweak their code because, 
if you have 100,000 lines of business logic, having to change 1000 lines should 
be much lower risk than porting all 100,000 lines to another JS framework.

Also, there are layers to backwards compatibility.  If we create an 
mx.collections.ArrayCollection for Royale, that might save you from touching 
some lines of code, but what if some other part of your code assumed that 
ArrayCollection subclasses ListCollectionView, and so on?  The number of class 
dependencies that we'd have to mimic could easily extend into reproducing about 
90% of the APIs in Flex.  Flex did not have good separation of concerns.  We 
are not staffed to produce classes for 90% of Flex, and I personally do not 
wish to work on something like that.

Also, there is a really good chance you will have to change some of your code 
around ArrayCollection.  There are no weak references for event listeners in 
Royale, so if your code tosses out an ArrayCollection and expects it to be 
garbage collected, the Royale version will not get GC'd.  If Royale creates an 
ArrayCollection class that wraps an IList and you want to get rid of it, you 
will probably have to call a release() API or something like that.

So, I do not think it is practical to have zero changes to logic that accessed 
Flex classes.  The business logic that I think can be left untouched really 
should not take Flex classes as inputs.  IMO, there is a network layer that 
should abstract how the data is retrieved.  Your business logic should try to 
work with Arrays.  You would probably find it works much faster against Array 
instead of ArrayCollection.  The ResultEvent and FaultEvent should be part of 
the network layer.  And the ResultEvent handler should call some entry point in 
the business logic.

This network layer would be replaced by Royale classes.  The output that gets 
passed into the business logic would be the same arrays and function entry 
points.  If it is impossible or impractical to write business logic without 
Flex classes, I'm interested in knowing that classes are a "must have" and then 
we can consider mimicking those classes.  I would hope that ArrayCollection 
isn't one of them, or if it is, then nobody cares whether it is a 
ListCollectionView or not.  I could imaging mimicking Sort/SortField, but 
really, you should pass in a sorted Array to the business logic.  And then the 
use of ArrayCollection is in the Network layer and you can make calls to an 
ArrayCollecition.release() if you need to.

I wish it could be easier, but I don't know of a practical way to make it so, 
at least without more folks writing framework code.  But it still should be 
much easier and safer than porting every line of code to a new framework.

My 2 cents,

From: Piotr Zarzycki 
Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>" 
Date: Monday, February 19, 2018 at 2:10 PM
To: "users@royale.apache.org<mailto:users@royale.apache.org>" 
Subject: Re: Substitutes in Apache Royale

So you basically would like to in your code avoid changes FaultEvent to Event 
everywhere ?  Yes ? That's the point in your case of having typed events for 
AMF handlers ?

2018-02-19 23:06 GMT+01:00 Carlos Rovira 
All AMF/RemoteObject API worked with that. And our AMF/RemoteObject 
implementation in Royale does the same. In fact we already have FaultEvent and 
Result Event... why don't use it? seems to me more complicated to change it to 
no use that...
Our code relies heavily in AMF so all that classes are in lots of code to 
manage the use of the incoming data for the server and that data is what gives 
the result object from the backend to the client to manage it,

2018-02-19 23:00 GMT+01:00 Gabe Harbs 
I don’t use AMF, but I have no idea why you need specially typed events for 

Maybe I’m missing something…

On Feb 19, 2018, at 11:38 PM, Carlos Rovira 
<carlosrov...@apache.org<mailto:carlosrov...@apache.org>> wrote:

Hi Harbs

2018-02-15 10:53 GMT+01:00 Gabe Harbs 
None of the cases where I had ResultEvent and FaultEvent really made a lot of 
sense to keep that logic in Royale (events should generally be of type Event), 
so keeping those events would just mask places where code should probably be 

I think you was not using AMF. With RemoteObjects, I think Fault and Result 
events are a must or at least I can't imagine a way to handle the async 
behavior in other way. Maybe your scenario was different right?

Carlos Rovira

Carlos Rovira


Piotr Zarzycki


Reply via email to