Glad to see that Orx is still in so activity development.
I knew the Orx was very deep dependent on config file which is a type like MS ini. And I was stuck by the simple file format with very flexible usage.
When I study the rust recently, I found it use a similar config file type which named toml(
https://github.com/toml-lang/toml), what make it more useful is that toml is not just a MS ini type config but a complete language.
Maybe you should try it.
Comments
It does look very similar.
Thanks for posting about TOML.
I do like that it supports nesting (albeit I'm not 100% convinced by the syntax), however it lacks binary/hexa numbers and inheritance.
I'm not sure I follow what you mean by "a complete language". Would you mind giving some details?
Enobayram: nesting is really neat for data serialization, however, in the context of orx, where do you feel like you're missing it? Maybe something can be done to improve that on the engine side?
Most of the time just a config item containing a list of sections fulfills the role of nesting. Though my main problem with lists is that they're not good for composition. They don't allow the @[Section][.Key] syntax, and they're not extendable. I.e. if a base section has a ChildList, and you need to extend it, you need to copy-paste(and maintain) the base's list. Finally, they're also a bit error-prone, as you can easily forget to add, say, an animation link in an animation set and wonder why the animation sequence is not right. That said, I'm not sure a nesting syntax alternative would be an improvement over either of these problems except the last one.
Another thing I'd hope to achieve with nesting would be the ability to use identical names for different things in different contexts. This is rather a namespacing issue. For example, different kinds of bird objects could have "Flap", "Land" etc. animations. Now it has to be "SparrowFlap", "SparrowLand" and if I need to write some generic code, I need to manually append "Sparrow" (more generally "$OBJECT_NAME") in the beginning of them. You can of course have a "FlapAnim = SparrowFlap" item inside the [Sparrow] section, and that's also better for composition and inheritance.
BTW, now that we're talking about the config system, have you considered multiple inheritance? I'm not sure if that would be a good thing over all, but I do need it sometimes. Specifically, I mostly need it when Scroll is involved. Sometimes, two objects corresponding to two different scroll classes need to share some traits, and inheritance stops being an option. Note, as I said in the beginning, there are ways to compensate for it (The @ syntax, code etc.), and I'm not sure if multiple inheritance is the right answer.
I'm sorry I made metion of Toml not by nest, I mean it's a language which is standardization, so everyone familiar with it could accommodate to it quickly.
By the way, Toml defined the types, Array, Table and the format, what make it better is it supported by editors(like Atom, Vim, Emacs),
And maybe Orx could use it to lighten the burden to maintain a type itself and use more time to do other things.
That's true, but I'm always happy to simplify things for the users when possible.
I've long been wanting to add a way to append elements to a list. I should probably get to it someday soon.
Animation itself is definitely a nightmare, due to historical reasons. On the project I'm currently working I've simplified animation declaration a lot.
I've had to deal with the same issue over the last 6 years and I don't think I've found a better to handle it than what I originally did with Mushroom Stew: adding an indirection layer that is directly handled at the Scroll level. I've pushed the concept a bit more on the project I just mentioned as kept the declarative part as its minimum.
I'll try to write a proposal on orx-dev to see how you all feel about me trying to retrofit what I did on that project directly in orx and/or Scroll.
Regarding multiple inheritance, I have the feeling it'd add much complexity and corner cases (such as diamond inheritance conflicts) that wouldn't be worth it.
If you have a concrete example of the problem you mentioned, it'd be useful as a start to find possible solution that could be implemented in orx, beside multiple inheritance
We can discuss config improvement on orx-dev if you feel like it. Things like maybe adding a += operator for list appending and a way to do some kind of implicit nesting. For example, something like this:
If [Object] doesn't have a Body key, then Object.Body would then be fetched automatically. Maybe the syntax could be even more compact. Something like:
Which reminds me that I wanted to add something similar for direct config value referencing. Let's say we have:
Then "Object.Graphic.Texture" would automatically follow the referencing and yield the value "texture.png". The biggest issue with this being list element referencing.
Anyway, this is a large topic and any ideas are welcome.
PS: As long as we're here, why not add some color literals as well.
Editor support is definitely a plus. However I think it'd be easier to add editor support for orx's config format (like it was done in the past for Notepad++, for example), than changing the interpreter to comply with TOML (which isn't definitive yet as it's currently at 0.4 and can change till 1.0) and add all the missing features such as inheritance, immediate commands, randoms, hex/octal/binary, etc...
Also, there isn't really any work done to maintain the config system in orx beside occasional new features.
That's true. But I believe it'd be much more work to do that than create editor langage support for orx's config syntax.
Great! I'm looking forward to it. I see that the lack of nesting in Orx is a superficial one. The only concrete situation that requires it is when you want to iterate over a range of sections without enumerating them in a list somewhere. I think would be solved if orx provided a way to efficiently iterate over sections in the alphabetical order, so that you can iterate over the ones that start with, say, "Sparrow/", but I guess you're keeping them in a hash table so that requires some redundancy.
I agree that multiple inheritance is calling for trouble. Though I'm not sure if diamond inheritance would be a problem. The way it currently works now is that in order to find a key, you traverse the inheritance chain and return the first occurrence, right? With multiple inheritance, you'd do the same over the inheritance tree in a depth-first manner. In C++, diamond inheritance is a problem due to the varying state of duplicate bases, in orxConfig, sections are logically singular (i.e. there's only one section with that name, and anything that refers to it is referring to the same unambiguous instance.). Note: I'm still not arguing for multiple inheritance
Unfortunately, I'm not able to pull something off the top of my head. I just remember thinking "I wish config had multiple inheritance" many times in the past. I'll note down why I think that and how I work around it the next time it happens and let you know in orx-dev.
Great! Just a small note, += is a great idea but it still wouldn't allow merging two lists. I think I should carry this discussion to orx-dev though.
Also great
I'd love to take part in all these discussions, so I'll visit orx-dev.
Indeed. But if the use case can be generalized for good practices, I don't mind adding something like a trie if need be. I could take the one that's inside the command module and provide it in the same way linklists and trees are.
You're definitely right, what I meant is that: how do we handle the case where a key has a different value per parent?
Sounds good!
Are you using the default section as well? For example, mine often looks like something like that: