My 2 cents are:1. we're using the xml form of the api on 32bit development machines and it works fine. 2. not supporting 32bit machines seems like a bad idea for twitter and developers, no matter who(twitter or php) you want to blame as the problem; a) PHP is perhaps the most popular web development language out there, so why make this difficult. b) the cost of a 64 bit machine is more than a 32 bit one and this cost matters to startups 3. conversion to strings is a "good idea"... it's a red herring to talk about space, since once you get the data you can convert it as you wish, and it goes over the wire as a string in any case (doesn't it)
jeffrey greenberg http://www.tweettronics.com http://www.inventivity.com On Thu, Sep 24, 2009 at 8:34 AM, Jesse Stay <[email protected]> wrote: > On Thu, Sep 24, 2009 at 9:26 AM, Dewald Pretorius <[email protected]>wrote: > >> This goes for any large numbers, including tweet ids. As far as I am >> concerned they can output everything in JSON as strings. >> >> > That would create quite a memory footprint! I prefer to use ints where > possible and strings only where necessary. I think it would be to your > benefit to just convert to 64-bit PHP. While PHP is type-less, other > languages aren't, and converting back to int is much more a pain in C than > it is in PHP. I suggest Twitter leave it the way it is - it should be up to > the end recipient to convert it in a way that works. Maybe write some new > JSON libraries that parse it correctly? That's what open source is for. > > Jesse >
