ZITIL - Utility Library

Showcase your libraries, tools and other projects that help your fellow love users.
Post Reply
User avatar
ZodaInk
Prole
Posts: 18
Joined: Thu Jan 08, 2015 5:18 am

ZITIL - Utility Library

Post by 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
Last edited by ZodaInk on Tue Oct 11, 2016 5:37 am, edited 1 time in total.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: ZITIL - Utility Library

Post by 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.
When I write def I mean function.
User avatar
ZodaInk
Prole
Posts: 18
Joined: Thu Jan 08, 2015 5:18 am

Re: ZITIL - Utility Library

Post by ZodaInk »

Thanks for the feedback!

I removed the do...end blocks and renamed 'data' to 'serialize'.
User avatar
pgimeno
Party member
Posts: 2602
Joined: Sun Oct 18, 2015 2:58 pm

Re: ZITIL - Utility Library

Post by 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?
User avatar
ZodaInk
Prole
Posts: 18
Joined: Thu Jan 08, 2015 5:18 am

Re: ZITIL - Utility Library

Post by ZodaInk »

pgimeno wrote: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?
pgimeno wrote: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.
User avatar
pgimeno
Party member
Posts: 2602
Joined: Sun Oct 18, 2015 2:58 pm

Re: ZITIL - Utility Library

Post by pgimeno »

ZodaInk wrote: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
ZodaInk wrote: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).
User avatar
ZodaInk
Prole
Posts: 18
Joined: Thu Jan 08, 2015 5:18 am

Re: ZITIL - Utility Library

Post by ZodaInk »

pgimeno wrote: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.
pgimeno wrote: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?
User avatar
pgimeno
Party member
Posts: 2602
Joined: Sun Oct 18, 2015 2:58 pm

Re: ZITIL - Utility Library

Post by pgimeno »

ZodaInk wrote: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.
ZodaInk wrote:How about letting the user pass a number from 2-36 or their own string?
Sounds good as well.
Post Reply

Who is online

Users browsing this forum: No registered users and 18 guests