4 ms·
Agreed. And also, there's not a lot of manipulation/math to be done on these IDs once they come back to the client. They're only used again when an operation ha
by flyosity 16y ago
Agreed. And also, there's not a lot of manipulation/math to be done on these IDs once they come back to the client. They're only used again when an operation happens on a tweet (favoriting it, replying to it) and in that case you're just taking the ID and sending it back to Twitter.
- riffraff 16y agonot really. You (can) use since_id and max_id in many places, which means you need them to be ordered (and trivially so). This is of course doable with strings too, once you decide what the ordering is.
- flyosity 16y agoTweets come back ordered newest to oldest so there's nothing to order if you don't want to. And accessing since_id or max_id just to send it back to Twitter is exactly what I was referring to: no math to be done, just storing & accessing a value so it doesn't have to be in number format. In a more practical application, a timeline comes back and the top-most and bottom-most IDs are stored. When a user gets to the bottom an API call is made to load more so you look at the bottom-most ID. If they want to load new tweets you look at the top-most ID. No math needed, just looking up values. They could've been strings all along and it wouldn't have mattered much.
- riffraff 16y agoI said that there are more operations than favouring and replying by id. I don't understand how saying you're gonna access the timeline without looking at the values denies that. Moreover, I did not object to using strings, I said you only want them to be orderable.