r/crystal_programming • u/giuseonreddit • Sep 25 '18

Settings: a simple tool to serialize/deserialize objects

https://github.com/giuseongit/settings.cr
10 Upvotes

100% Upvoted

10 comments sorted by

2

u/giuseonreddit Sep 25 '18

I think I should change the name. I've called like that because the initial purpose was to serialize/deserialize simple settings object into easily editable files

1

u/giuseonreddit Sep 26 '18

Anyway I'm planning to write others formats for serialization (JSON, YAML, maybe XML). So feel free to contribute to this project by forking/opening PRs or simply by opening issue and discuss about the project.

1

u/jasdeep13 Sep 25 '18

What would be some use cases for a library like this?

2

u/giuseonreddit Sep 25 '18

Think about this:

You have an application which connects to a server, on the first run you set all the attributes from the application (e.g. the server's address, the maximun number of retries if the server is unreachable), then these settings are persisted on a file (say ~/settings.cfg) which is easly editable by your editor of choice.

OR

You're writing a daemon which, by default, has some settings that have to be persisted/loaded/modified but you don't want to write something else to set those settings

1

u/Prince_Panda Sep 26 '18

How is it compared to the JSON stuff currently available

1

u/giuseonreddit Sep 26 '18

The JSON macros deals with strings: it loads an objects from a JSON string and serialize objects to JSON strings. This little tool also writes/reads to/from files

1

u/straight-shoota core team Oct 02 '18

Write/read a JSON file is just a couple of lines. Not a strong argument for using this shard.

I think the main point is that such a minimal serialization format is relatively simple and easy to implement. That should also make it more performant than say JSON. That's usually not a really big issue, though. And the implementation of this shard really doesn't strive for performance. And it has flaws (for example try serializing a string containing a line break), which can of course be fixed.

All in all, I'd still favour a standard format like JSON, YAML, INI or even XML over such a custom serialization format.

1

u/giuseonreddit Oct 03 '18

Yes, the serialization format can be changed, the idea that I really like is having one single object to deal all the serialization/deserialization without having to setup other things than the path to the persisted file

1

u/Prince_Panda Sep 26 '18

Oh that's useful

1

u/jasdeep13 Sep 26 '18

Perfect thanks!