About the config file format. Try toml.

edited August 2015 in General discussions
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

  • edited August 2015
    Hi jtianling!

    It does look very similar.
  • edited August 2015
    I like how you can nest sections. That's one feature I miss in orxConfig (though not badly).
  • edited August 2015
    The current config does work beautifully for me. It would be kind of cool to be able to define a variable and have extra config load in based on the value, but really... you can load in extra via code anyway. And I think I prefer controlling this via code anyway.
  • edited August 2015
    Hey jtianling, long time no see!

    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?
  • edited August 2015
    As I said, I don't need it so badly. After all, any shortcomings of the config system could be compensated from the code 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.
  • edited August 2015
    long time no see~

    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.
  • edited August 2015
    Toml is just a format define for a config language, it don't mean we can't implement inheritance ourself. But a standard base is still mean something...
  • edited August 2015
    enobayram wrote:
    As I said, I don't need it so badly. After all, any shortcomings of the config system could be compensated from the code side.

    That's true, but I'm always happy to simplify things for the users when possible. :)
    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.

    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.
    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.

    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.
    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.

    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:
    [Object]
    Color = (0, 0, 0)
    
    [Object.Body]
    Dynamic = true
    

    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:
    [Object]
    Color = (0, 0, 0)
    Body.Dynamic = true
    

    Which reminds me that I wanted to add something similar for direct config value referencing. Let's say we have:
    [Object]
    Graphic = G
    
    [G]
    Texture = texture.png
    

    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. ;)
  • edited August 2015
    jtianling wrote:
    long time no see~

    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.

    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.
    Toml is just a format define for a config language, it don't mean we can't implement inheritance ourself. But a standard base is still mean something...

    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.
  • edited August 2015
    iarwain wrote:
    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.

    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.
    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.

    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 :)
    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 ;).
    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.
    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....
    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.
    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:...
    Also great :) I currently use
    [Object]
    Body = @
    Dynamic = true
    
    to that effect, and I don't know how I feel about it :) It gets the job done, it even allows child sections to modify "Body" parameters conveniently.

    I'd love to take part in all these discussions, so I'll visit orx-dev.
  • edited August 2015
    enobayram wrote:
    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.

    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.
    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 :)

    You're definitely right, what I meant is that: how do we handle the case where a key has a different value per parent?
    [ParentA]
    Key = Value1
    
    [ParentB]
    Key = Value2
    
    [Child@ParentA@ParentB]
    ; Key = ?
    
    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.

    Sounds good! =)
    Also great :) I currently use
    [Object]
    Body = @
    Dynamic = true
    
    to that effect, and I don't know how I feel about it :) It gets the job done, it even allows child sections to modify "Body" parameters conveniently.

    I'd love to take part in all these discussions, so I'll visit orx-dev.

    Are you using the default section as well? For example, mine often looks like something like that:
    [Default]
    Graphic       = @
    KeyData1      = @
    Pivot         = center
    KeepInCache   = true
    Interpolate   = false
    
Sign In or Register to comment.