Harbs, FYI I have made progress on this and expect I will have something to share with you in a couple of days.
What is your preferred way to submit a patch for review? Is it easiest to make a pull request against the github mirror? (I use git a lot, but have somehow avoided making a pull request for anything so far, so this would be something new for me!). Otherwise I can link to or send patch files etc - whatever works best. cheers, Greg On Thu, Jul 14, 2016 at 9:38 PM, Harbs <harbs.li...@gmail.com> wrote: > FYI, I just added an “array” getter which returns the underlying array of > bytes. The exact type is different on the different platforms. > > Alex, I tried to make the type “TypedArray” instead of “Uint8Array” on the > JS side, but TypedArray was not recognized for some reason. Any ideas on > why that might be? > > Harbs > > On Jul 14, 2016, at 9:33 AM, Greg Dove <greg.d...@gmail.com> 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. > > > > 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 <aha...@adobe.com> wrote: > > > >> > >> > >> On 7/12/16, 3:57 PM, "Greg Dove" <greg.d...@gmail.com> 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 > >> > >> > >
