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. 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. cheers Greg On Wed, Jul 13, 2016 at 6:46 PM, Alex Harui <[email protected]> wrote: > > > On 7/12/16, 3:57 PM, "Greg Dove" <[email protected]> wrote: > > >I have dipped my toes into FlexJS for the first time. I am evaluating > >FlexJS for a migration away from Flex4/flash and figured I would try to > >cross compile an isolated a3 library that is a core dependency for my > >client's project. > > > >It seems there is no direct substitute for flash.utils.ByteArray on the js > >side, The nearest I could find was org.apache.flex.utils.BinaryData which > >seems to be a partial proxy implementation for ByteArray. > > > >BinaryData does not implement IDataInput and IDataOutput and therefore > >cannot simply be used in place of the original ByteArray in arbitrary > >code. > > > >Is this intentional? Or is this WIP, with a plan to get to the original > >interfaces? Or am I looking in the wrong place for what I am trying to do > >(entirely possible!). > > IMO, FlexJS is a WIP, but there is no "plan" per-se. > > Unlike Flex, FlexJS is intended to support multiple component sets. The > Basic set we have released so far is meant to thinly wrap Browser/HTML/JS > APIs so that when you compose an application, the result has as little > overhead as possible when compared to writing an HTML/JS app directly in > JS. It isn't a goal for these components to emulate Flash. Instead, the > SWF versions of those components are trying to emulate the browser. > > There is an experiment under way to try to see how hard it would be to > make a component set that supports most (but not all) Flex APIs. We > received several opinions that the Basic set is too big of a migration > step for existing Flex code bases. Flex is already heavy so making a > heavy component set that lowers migration pain by spending code on > emulating more of Flex in the browser might be viable. This component set > is a ton of work and isn't a top priority on my list right now and could > use more volunteers to help. > > ByteArray isn't even a Flex API. But it is often used so I suppose a > component set that emulates Flex will likely have to support most of > ByteArray. The Basic set is supposed to be pay-as-you-go and use plugins > for additional functionality, so IDataInput/IDataOutput might be replaced > by plug-ins that support similar APIs. > > But really, what actually happens is often up to the person that codes it. > We don't have resources to mark every API as needing implementation, and > since we want to make many implementations as plugins, the API may not be > the same anyway, so we just need folks to jump in and deal with holes in > the documentation and code and help make things better for the next person > who jumps in. > > HTH, > -Alex > >
