rmcafee / discord_ex

Discord Elixir Library
MIT License
48 stars 13 forks source link

Snowlake IDs are sometimes string, sometimes integer. #11

Open Marqin opened 8 years ago

Marqin commented 8 years ago

Look at this payload.

Channel ID is integer. Author id is integer. Message id is integer.

But when asking about User.current(state[:rest_client]) the result user ID is a string.

This should be uniformly treated in all places as a string or integer (preferable string, as Discord API uses strings for that).

iex(9)>
    "author" => %{"avatar" => "ac4066c6fb7c329e0cbdf9c88139a2e5",
      "discriminator" => "3379", "id" => 153225472447086593,
      "username" => "Marqin"}
    "channel_id" => 193682812925116416
    "id" => 218812642570141696
Marqin commented 8 years ago

Ok. I've talked with guys on discord API server (that one from #2) and this is what I get to know:

Marqin commented 8 years ago

I think it's better to stay with ints (their comparision should be faster than strings?).

The question is, what to do with REST api? Leave it as string as just document it in README that it uses strings, or we cast it somewhere internaty to integers? (it can be hard to find all usage places)

jhgg commented 8 years ago

the reason the HTTP api returns strings is because javascript would truncate the number to 53 bits if it was sent as a number.

on our client - our ETF parser (http://github.com/hammerandchisel/erlpack) (which is C++) converts the large ints over the wire to strings for JS.

I'd be open to exposing a header that you can send with the request that tells the server not to do the conversion though if your client /can/ handle ints this large.

Marqin commented 8 years ago

@jhgg Thanks for explanation. And yes, header for that would be helpful.

Marqin commented 8 years ago

I made suggestion on Discord Feedback for this.

Marqin commented 7 years ago

@jhgg this proposition has been removed from uservoice without reason :/ Does this need any community help for changes in erlpack?