HI Greg, It’s definitely a WIP although the latest build is pretty complete already. I don’t know if it’ll ever be a complete drop-in for ByteArray, because indexed access is cumbersome to implement efficiently.
I recently added a number of methods to BinaryData to implement the parts of ByteArray that I was personally using. If you check out the latest nightly build, you’ll see the changes. I was not aware that ByteArray implements an interface. I’m not sure whether it makes sense to use an interface in FlexJS. FWIW, I just finished replacing ByteArray with BinaryData in my project, and the current implementation works as a drop-in replacement in almost all cases. Which methods do you need that’s missing? Harbs On Jul 13, 2016, at 1:57 AM, 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!). > > If BinaryData is ultimately intended as a drop-in replacement for ByteArray > I guess my question right now is why does it not implement those interfaces > as it is and contain unimplemented stub methods/getters/setters etc on the > js side for the unimplemented parts? (even with 'throw new > UnimplementedError()' during WIP, or something else that clearly shows > intent - and possibly guides people to contribute the specific missing > parts)
