It looks like you're new here. If you want to get involved, click one of these buttons!
[Template]
MyKey = @; <= The value for 'MyKey' will be 'Template', the name of this section
MyOtherKey = @; <= Same here, the value for 'MyOtherKey' will also be the name of this section: 'Template'
[MyObject]
Graphic = MyGraphic
[MyGraphic]
Texture = my-texture.png
[Object]
Graphic = @
Texture = my-texture.png
Comments
All it actually does is replace the value by the current section name itself. So what it's giving you is the "mashing effect" not only for this section but also for all the sections inheriting this one as well.
In your example:
Translates to:
Which you could have written yourself explicitly. However, if you now consider this "child":
In this case, @ morphs into the child's section name, so it would be like having typed:
So to say:
"replace the value by the current section name itself"
Config property values do more than this. Rather than replacing a "name", the value indicates a "section" where to source data from.
So from the example earlier:
[MyObject]
We're saying, instead of getting the Graphic information from another section, get it from THIS section, the "MyObject" section.
I'm really just quibbling over language I suppose, because for a long time I couldn't see the value of placing the current section "name" into a property.
It's because in this example you know that the value of Graphic will be used to push a section, but it doesn't have to be the case all the time.
If I do:
The value of that property itself will still be "MyObject" when "MyObject" is the current section, but you can't assume someone is going to push that content. They might simply print it somewhere or use it for any other purpose, like as part of some string concatenation to form an ID, etc.
I guess you might not have seen the value of this because maybe you were not conflating sections manually before?
Before "@" was introduced, I would often write things like:
etc, instead of having separate sections all the time.
In both examples, they are object sections.
In the previous cases, doing "section mashing" with @ appears to be for a completely different use, whereby object sections and graphic sections all become one.
But as you say, I haven't really needed to construct IDs and other use cases yet, as I see in orx/Scroll examples. I guess that's why I'm looking at this syntax.
The inheritance there was just to point out how much redundancy was needed beforehand, as you couldn't simply define the keys in the parent and expect them to point at the children, you'd still need to explicitly define all the keys in the child pointing at the child itself.
Also, I took object examples by habit, but it really doesn't matter what they are. Consider the examples below:
That only is already error prone, as if you rename the section itself, you need to remember to rename all the values too. And of course, with inheritance, in the children, you still need to explicitly re-define all the keys again, with the correct values.
As long as we're on this topic, I'm also using the default section feature: one can define a default section for config and if a key isn't found in the current inheritance hierarchy, orx will check the default section for that key.
I usually put this kind of things in it:
@: