On 7/13/16, 11:33 PM, "Greg Dove" <[email protected]> wrote:
>Harbs and Alex, thanks for your explanations. > >I guess 'drop-in' replacement is quite unrealistic. But I think if could >be >closer to the IDataInput/IDataOutput, and given that ByteArray is a common >utility class in many libraries, particularly for low-level parsing of >various formats, the closer the better imo. > >In my experience most ByteArray use seems to be mostly sequential reading >or writing which uses the flash class' read/write methods instead of array >access. So in terms of migration effort, swapping array access out >wherever >it is used to the method-based getByteAt, setByteAt is not so bad. When we get around to needing a better ByteArray for the MX/Spark emulation, I may look into having the compiler handle [] accessors on ByteArray. We have it working for Proxy already. For the Basic set, I would still opt for pay-as-you-go plug-in capabilities. You can aggregate those pieces into a big heavy drop-in replacement of ByteArray, but folks who don't need all of that can only pay for what they need. > >Harbs, I picked up the recent updates from nightly and there is more there >than what I had for sure, but more to do I think - perhaps I can help - I >will try to work on this over the next day or so and share where I get to. >After using Flex for 8 years I am kinda struggling with my setup for >FlexJS, and I'm not sure if I can use monkey-patching for checking the >additions I have in mind.... which I could do in the past with the regular >flex sdk. Standard monkey-patching would work for the SWF version of the code. We don't have a similar workflow for the JS version. Instead, you can hand-edit the cross-compiled JS output and store it in the frameworks/js/generated-sources folder. It would be great to have you push on trying to port your app and contribute to FlexJS. A key thing about Apache projects is that there is no upper management deciding what code gets written next. You can write what you need when you need it. FlexJS won't be a 100% drop-in replacement for Flex, at least not in the short term. Its goal is to be less work and risk than porting all the way to another JS framework, and to save you time maintaining that code going forward since you can use structured languages and declarative languages all from a single vendor. And there is no corporation that owns the technology that can decide to change directions. Many of the most popular JS frameworks have corporate influence. -Alex
