ZITIL - Utility Library

[ZodaInk]

I present to you: ZITIL - (ZodaInk's Utility Library)
It's a set of mostly non-game-engine specific tools. It is in an early stage, but I wanted feedback.

Source: https://github.com/ZodaInk/zitil
Documentation: https://github.com/ZodaInk/zitil/wiki

[kikito]

I gave it a quick glance.

The first thing that you should do is come up with a better name than "data" (and "data handling"). As a general rule, the more a name sounds like "thing" and "managing" (which means "doing things"), the worst it is. "Data" is very close to "thing" and "handling" is the same as "managing". By looking at your source code it seems that it is doing serialization.

Second, I see that you use lots of do ... end blocks inside your files. If you declare something as local in the "root" of a file (without do...end), it is not available outside. You don't need all those do ... ends. They make the code harder to read.

[ZodaInk]

Thanks for the feedback!

I removed the do...end blocks and renamed 'data' to 'serialize'.

[pgimeno]

Nice to see a de-serialization routine that doesn't just loadstring() the file. I'm not sure if inf and nan will work the same in all machines. In Lua they can be represented with something like #PINF or similar; not sure about LuaJIT.

One question. Why is the base64 character set called base37?

[ZodaInk]

Nice to see a de-serialization routine that doesn't just loadstring() the file. I'm not sure if inf and nan will work the same in all machines. In Lua they can be represented with something like #PINF or similar; not sure about LuaJIT.

I really don't like decoding with loadstring(), it seems like a hack.
Should I represent inf as 1e+9999 like in JSON then?
And how would I represent nan? Would tonumber("nan") do the job? Or function(num) return num ~= num end?

One question. Why is the base64 character set called base37?

Because it is base 37 and above. If you add more characters to it, it becomes base 65, 66 and so on.

[pgimeno]

Should I represent inf as 1e+9999 like in JSON then?

And how would I represent nan? Would tonumber("nan") do the job? Or function(num) return num ~= num end?

I'm not sure if it's a concern, because it seems that LuaJIT is consistent across platforms. But in case you want to handle it to be sure: 1/0 and 0/0 give you inf and -nan in Lua, and -(1/0) and -(0/0) gives you -inf and nan. The tostring of that is what you can compare with. You can take a look at how it's handled here: https://github.com/gvx/Ser/issues/1 and https://github.com/gvx/Ser/issues/4

Because it is base 37 and above. If you add more characters to it, it becomes base 65, 66 and so on.

Hm, OK, but it's a somewhat confusing name. There's also the issue that with base 36 the first digit is 0, while with base 37 the first digit is A. That's also inconsistent. I'd suggest the following API instead: let the user pass their own digits string as an argument to the function, and provide a couple defaults (base36 and base64).

[ZodaInk]

I'm not sure if it's a concern, because it seems that LuaJIT is consistent across platforms. But in case you want to handle it to be sure: 1/0 and 0/0 give you inf and -nan in Lua, and -(1/0) and -(0/0) gives you -inf and nan. The tostring of that is what you can compare with. You can take a look at how it's handled here: https://github.com/gvx/Ser/issues/1 and https://github.com/gvx/Ser/issues/4.

Hmm, I think storing tostring(inf) is a better idea than having str:find("^inf") hardcoded.
I'm not sure if I want the serialized string or the de-serialized value to be consistent across platforms.

Hm, OK, but it's a somewhat confusing name. There's also the issue that with base 36 the first digit is 0, while with base 37 the first digit is A. That's also inconsistent. I'd suggest the following API instead: let the user pass their own digits string as an argument to the function, and provide a couple defaults (base36 and base64).

I guess it is confusing. The reason why base 37 and above starts with A is because it's the "standard" way to encode base64.
Having users pass their own string is a good idea! I think I like that better.
How about letting the user pass a number from 2-36 or their own string?

[pgimeno]

Hmm, I think storing tostring(inf) is a better idea than having str:find("^inf") hardcoded.
I'm not sure if I want the serialized string or the de-serialized value to be consistent across platforms.

It sounds like a good idea to do that conversion (e.g. inf to 'inf', nan to 'nan') and then convert back.

How about letting the user pass a number from 2-36 or their own string?

Sounds good as well.