-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not treat as object when mixing key types? #12
Comments
Can you provide any examples of where this behaviour would be useful? The library encodes the input value you provide as JSON — if it converted numbers to strings the JSON would no longer represents the data you provided. If you decoded it it wouldn't be the same data that you started with. I can't think of a scenario where this kind of automatic conversion would be beneficial. |
Yeah, you're right. In my use case, I'm using this to convert tables into strings which can then be obfuscated back and forth and then converted back to tables from strings. I'll probably make a modified version which can allow the mixed keys and just assume that strings from the JSON which are numeric are to be numbers as keys in the tables. |
If you're only using the serialised data with your own program and don't need a standard format you might be better served using something like serpent. This would allow you to serialise data that wouldn't be directly mappable to JSON, such as tables with non-string key types. |
And then allow numbers for keys too, is there a technical reason why it shouldn't be done?
The text was updated successfully, but these errors were encountered: