I don't think anyone's saying it's Twitter's problem (at least I hope
not).  It's the same issue as supporting Internet Explorer.  You can
bitch and complain all you want about IE not supporting standards but
if it's the most popular (or one of the most popular) browsers that
are in use --- then practical beats principle.

My suggestion was to return everything as a string if that's how it's
being requested.  It's a safe backwards compatible addition that
doesn't affect anyone that doesn't run into this problem.

If your scope is limited to what startups can or can't afford, then
that's really narrow.  This applies to anyone consuming the API be
than on a laptop for development or anything else.

On Sep 25, 12:23 pm, David Fisher <tib...@gmail.com> wrote:
> I'm sorry, but the problem isn't Twitter- its your language and JSON
> parser. Outputting everything as a string, when it clearly should be a
> number, is inefficient and crazy.
> Saying that startups can't afford 64 bit processors in systems is
> crazy. Most startups I know are running on EC2 or have fairly new
> hardware. I bought a killer 64-bit quad xeon server for less than
> $1,500 for our startup and its rocking. If your startup doesn't have
> $1,500 for a primary capital computing expense that's another problem
> you have there.
> You either need to run on a newer system or use a language that can
> properly handle 64-bit numbers. C, Python, Ruby, Scala, Erlang, C#,
> etc.... none of them have problems with 64-bit ints.
> Not a Twitter problem. It's a programming issue on your end and
> unfortunately I can't help as I don't know PHP in depth.
> -dave
> On Sep 24, 3:29 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> > That magical maximum number appears to be 1000000000000 (1.0E+12).
> > So, for tweet ids we still have a bit of breathing space.
> > Dewald
> > On Sep 24, 4:18 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> > > Clearly PHP_INT_MAX plays no role in json_decode.
> > > There must be some other mystical maximum number above which it
> > > represents the number as float in the decoded data.
> > > Dewald

Reply via email to