Harbs, FYI the changes I made do not alter the behavior that was there originally, but they do provide the user with more information, and also retain the optimal code path after a BinaryData has had an explicit endian value set.
Flash continues to default to BIG_ENDIAN as before. I don't actually know if the native flash bytearray is faster in the same mode as the hardware or not... perhaps that is something to check. So now (in javascript only, not flash) it will pretty much show new BinaryData().endian == Endian.LITTLE_ENDIAN and you can still check whether the BinaryData is in the optimized mode via new BinaryData().endian == Endian.defaultEndian; but you can also check (independent of BinaryData, for example) if the system optimized endianness is little endian or big endian: Endian.defaultEndian == Endian.LITTLE_ENDIAN Because the default setting on BinaryData is now a known optimized default, instead of "DEFAULT", the optimized branch of the read/write method inside the javascript code is still used when it matches the faster option after explicitly setting the endianness. Before if you did: var bd:BinaryData=new BinaryData(); bd.endian = Endian.LITTLE_ENDIAN; if would no longer have the 'DEFAULT' value and would take the 'DataView' path in the code. Now it will still use the faster fixed typearray options in the read/write methods. Actually I had another (unrelated) thought I think the writeByteAt and readByteAt methods could be renamed to getByteAt and setByteAt. Although it can be made clear in the docs that they do not alter the internal position point, this change would make them quite distinct from all the other read/write methods and (I think) closer semantically to the underlying array access implementation. Just an idea... Also what do you think about removing the data getter? cheers, Greg On Sat, Jul 23, 2016 at 4:26 AM, adufilie <g...@git.apache.org> wrote: > Github user adufilie commented on the issue: > > https://github.com/apache/flex-asjs/pull/10 > > Thanks for the link, Harbs. I mistakenly thought this code was only > related to ByteArray. Now I see that it's actually writing to an > ArrayBuffer in JavaScript. > > > --- > If your project is set up for it, you can reply to this email and have your > reply appear on GitHub as well. If your project does not have this feature > enabled and wishes so, or if the feature is enabled but not working, please > contact infrastructure at infrastruct...@apache.org or file a JIRA ticket > with INFRA. > --- >
