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 <jesses...@gmail.com> wrote:

> On Thu, Sep 24, 2009 at 9:26 AM, Dewald Pretorius <dpr...@gmail.com>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
>

Reply via email to