Configuration is a terrible enemy. It can be done at build time with dm source files, or at runtime in a variety of ways. The easiest are JSON or a line split file2text parser in DM lang.
Source configuration is fine but clunky - especially with projects like space station 13, you have significant build times and hungry players. That means infrastructure to pre-build changes and deploy to minimize downtime.
Line split stuff is fine, but there's only so much
SOME_OPTION stuff here #does the thing
someone can read before it becomes obnoxious.
JSON is fine but lacks comments. That's a pain because sometimes you need a sentence to explain something.
--
Adding TOML support would allow users - mostly server hosts, but any circumstance where a game supports significant configuration is a good case - to have much, much nicer configuration files in a way that doesn't require buckets of overhead or DM library code.
For readers in general, TOML is like a canonical INI file with a lot more fun stuff going on. It transforms straight into JSON, which means it transforms straight into a byond tree list / map. It also supports comments, multi-line strings, and all sorts of other lovelies that we do not have. TOML has also hit a fully stable 1.0 as of nearly two years ago with very, very mature libraries in a broad set of languages available.
https://toml.io/
I'm not sure which is more useful - a 1.0.0 C library, or CPP bindings for the same library.
https://github.com/cktan/tomlc99
https://github.com/cktan/tomlcpp
These have been near-reference for years. They are also 1.0.0 complete, and recommended by toml.io
ID:2814943
 Aug 25 2022, 7:25 am
|
|||||||
| |||||||
|
Aug 30 2022, 8:16 am
|
|
Jaredfogle
 |
FWIW we currently do this in SS13 by packaging it with rust-g.
|
More stuff shipped with byond means less stuff that needs call() and secondary parsing.
| |
To be honest I view TOML like a lot of markup languages as a flash in the pan, and don't see any significant benefit to built-in support. Something else will replace it in time. A BYOND library would be more than adequate for reading TOML.
| |
Fair enough!
| |
Something else will come out as “better” but TOML will stay due to its heavy usage in the Rust/cargo ecosystem. Personally I think TOML is great.
| |
True, but the only reason people are suggesting TOML in the first place for BYOND is because of some jury-rigged connections to Rust. JSON made sense to support because BYOND has a lot of reasons to integrate with JavaScript.
| |
The way I see it, TOML is just improved ini files, and ini files are the goto for a lot of application configuration.
I did bastardise TOML to JSON into an external lib a while ago, which does work, but I do agree having it native would be blessed. | |
I don't see this going anywhere but I thought I'd expand on my original post just over the "only reason people are suggesting TOML in the first place" part.
Contrary to this ask being in any way related to rust, at least for my part- I have been using TOML since its original spec and release, which was actually slightly *before* JSON's formal ECMA spec (if not the informational rfc and json2). It's my preferred configuration language. I avoid rust wherever I can. It's an unpleasant language to grok and write, in my opinion, and the contortions necessary to make it handle c strings as byond uses them make it instantly dramatically harder. I think there are significant merits to adopting a configuration language. JSON is a data language. You can use JSON as a configuration language, but like I said before - no comments (at least in the pure JSON we have with byond). It's also unfriendly to write and navigate for any large or deep options set. We also can't pretty-print it from the byond side, so creating a project that self-documents its configuration options is less friendly a process. A library to read TOML means writing (as Affected and Jared mention) something that consumes TOML, handles errors, creates JSON, then emits it back to byond land as a c string, requiring re-parsing. It's an option but an ugly one. If "flash in the pan" is a significant blocker (again, formal JSON/TOML same year) I grudgingly suggest YAML - since it's twice as old as either. :B | |
Ya, i kinda agree with lummox.
I'd like to see yaml support long before toml because yaml can parse json so at least it'd make sense to move over to it as it can do both yaml and json from one backend function. I kinda hate toml and hate that we use it at /tg/ and worry adding it to the engine might entice other devs into making the same mistake. | |
+1 to YAML support (and INI support because Lummox's point)
| |
+1 to YAML
| |
I do get there are benefits to a configuration language. Although I friggin' hate YAML.
| |
Spookerton wrote:
It's an unpleasant language to grok and write, in my opinion, and the contortions necessary to make it handle c strings as byond uses them make it instantly dramatically harder. At the risk of derailing the thread slightly, I just want to state my confusion about Rust being unpleasant or any difficulty working with C strings. | |
"Unpleasant" is a matter of opinion, regardless of how many other people agree or disagree. I also notice that JavaScript, which is almost memetically bad, breaks 60% loved in that survey.
| |
Lummox JR wrote:
I do get there are benefits to a configuration language. Although I friggin' hate YAML.  | |
To be fair, a lot of why I hate YAML may have a lot more to do with the contexts in which I've seen it used.
| |