Skip to content
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

Parse table with booleans and numbers #1

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JavierLealCortes
Copy link

This PR allows to convert an arbitrary table to a string without losing type information.
Booleans are codified with special ASCII values and numeric values are codified as a string.
When a string value needs to be decodified, it will try to decode as a number first. If it's not a numeric value then it will be treated as a string.

The only caveat is that strings that represent numeric values would be mistakenly assigned to numeric values

* Parse boolean values
* String values that represent numeric values are now parsed as numbers
@ridgekuhn
Copy link

ridgekuhn commented Apr 23, 2021

@JavierLealCortes Just wanted to say thanks for this PR, I think it's exactly what I need for my project! Also, thank you @benwiley4000! I'm surprised this repo hasn't gotten more attention!

@benwiley4000
Copy link
Owner

Sorry, just saw this. I'm hesitant about the caveat. Do you think there's any workaround that isn't too complicated to avoid casting strings to numbers? I'll admit my use case was for serializing string tables.

@ridgekuhn
Copy link

You could probably just remove the call to parse() on the right-hand side of the assignment? (Also, is it necessary to use tonum() to access the table key anyway? I think Lua will coerce the type for you in that case?)

imo, as written, it's not a big caveat since tonum() returns falsy for anything w a non-numeric char and parse() would proceed to return the NaN value as a string. The only time I can think of that it would cause an issue would be if you tried to concatenate a number from the table without using tostr() on it first, which seems like an edge-case since I think you'd generally want/expect to treat any value containing only numeric chars as a number rather than a string?

@ridgekuhn
Copy link

btw, this branch was battle-tested through 90% of development for Downstream Dream. In the end, I wrote my own alternative that uses less characters to serialize the table to stay under the compressed limit (at the cost of more tokens to deserialize), but I had no issues with this branch otherwise!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants