Dewald sums it up great. I'm not affected by this issue but keeping the barrier of entry low is of high value. It sucks that some PHP installations have this issue, but if there's a good way to accomodate such a popular language then what's the harm?
This brings up an issue though. I'm not in favor of changing the default int to a string. It's the default that's important. Adding in an override parameter isn't really anymore helpful than suggesting to parse the json once you get it. Except, the thought of pre-parsing json (no matter how simple) makes my stomach churn. Think about it from the perspective of a developer that's just starting with the API. What would trip them up? If there's a way to resolve that, then that should be a high priority. For me it's not a big deal since I've used it enough and know people in the API community and this group where I can get an answer. That's a luxury I didn't have when I started though. So far, two proposed solutions: * Abraham suggested an additional key (this is great because you see it in the response without having to know of an additional paramter) * I suggested an additional parameter which would return all values as a string (drawback is that this is a bit more "hidden" - not everyone RTM :( ) * Your suggestion here! Think about the children! :) On Sep 25, 6:48 pm, Dewald Pretorius <dpr...@gmail.com> wrote: > I think the point that some folks are trying to make is that forcing > consumers of the API to use 64-bit machines is stifling innovation. > > Many Twitter apps start as pet projects hosted on a shared HostGator > or other provider's server for nine bucks a month. That's how mine > started way back. You don't have the option of editing php.ini or > running on a 64-bit machine, unless you want to reduce your groceries > per month and fork out more for a server. > > Dewald