peehaa / asynctwitter Goto Github PK

Currently all results and returned as dumb array "as is" from the api.

It would be nice if we convert them into proper object at the some point.

All calls should be checked and requests should be validated.

E.g. what happens when people use both the user ids and the screen names here.

If this fails the class should add constraints to prevent this.

Twitter message ids are very large, and are too big to be represented by a 32-bit integer. The int type hint on the declaration of \PeeHaa\AsyncTwitter\Api\Request\Status\Update::replyTo() causes a TypeError on 32-bit PHP:

TypeError: Argument 1 passed to PeeHaa\AsyncTwitter\Api\Request\Status\Update::replyTo() must be of the type integer, float given, called in D:\projects\phptek-asynch\twitter-bot.php on line 43 in D:\projects\phptek-asynch\vendor\peehaa\async-twitter\src\Api\Request\Status\Update.php on line 19

Originally I was thinking that this could be avoided by simply removing the type hints, but my testing shows that it won't work because PHP converts the integer to a floating point, losing some precision in the process as show in this partial print_r output of a status update:
Array ( [created_at] => Wed May 24 01:21:10 +0000 2017 [id] => 8.6718869400397E+17 [id_str] => 867188694003974148 )
The only solution is to require 64-bit PHP.

• Check all namespaces of examples
• Check all namespaces of tests
• Check all namespaces of source
• Explain project structure
• Update readme
• Check all namespaces of examples
• Add contribution notes
• Test the streaming API
• Branch out the v1 release to the v1 branch and move ampv2 development to master
• Write documentation
• Move all GET, POST and DELETE requests into their own namespace
• Check all parameters
• Rename all lang methods to langauge

All examples should be organized into their own directories based on the available endpoints.

All examples should use the create-client.php bootstrap file for easy setup and less chance of leaking credentials.

Twitter id's don't fit in 32b integers. Should we loosen the type declaration from int to string to support 32b systems?

Related to #12