Folks, After some further consideration, I think perhaps a better way to do this would be to represent i64 in AS3 generated classes as an arbitrary precision integer. This would allow transfer without loss for those who want it and would allow easy truncation for those who don't. There is an open source BigInteger class available as part of this library: http://code.google.com/p/as3crypto/
I believe this is the route we are going to take for our situation and I will submit a patch back to this project for your consideration once it is done. I am still interested in any feedback or suggestions that others might have for this. Thanks, Jason von Nieda On Tue, Feb 9, 2010 at 2:38 PM, Jason von Nieda <[email protected]> wrote: > Hi all, I am currently working on a project that has a multi-language > client API. We have decided to use Thrift as our wire level protocol. > I am in the process of adding AS3 support to our library and am trying > to decide how to handle Thrift types that contain long integers. The > rest of our supported languages (Cocoa, C#, Java) contain some type of > support for long and many of our structures contain longs. Of course, > AS3 does not have a long type and it's largest integer type is a few > bits short of handling a 64 bit long. > > Our application has previous support for long in AS3 by simply > discarding the top few bits as needed and storing the value in a > Number. This suits us as we generally only use longs for "largeish" > numbers and we have not, nor do we expect to, use the full 64 bits. > > All this being said, I am looking to add some type of support for long > into the current Thrift AS3 generator. I am using asogar's branch at > http://github.com/asogor/thrift-as3 as this seems to be the most > current implementation of AS3 for Thrift. The reason for my email is > to ask if there is any existing work on this or if there's any > particular direction it should be taken. I am willing to write a patch > that allows for decreased precision longs along with a configuration > option that allows this feature to be turned on and off. The off side > of the equation being answered by throwing an exception if a value is > received that is too large to fit in Number. > > So, does anyone have any thoughts on this? I'm willing to do the work > and submit the code back if there's a preferred direction that meets > our goals. Our goal, as plainly as I can put it, is that we'd like to > be able to successfully generate Thrift AS3 objects from Thrift IDL > containing i64 fields. I'm open to any reasonable option on how to > implement this. > > Thanks, > Jason von Nieda >
