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

Reply via email to