Struggling to understand @

edited April 2016 in Help request
So looking through the settingconfig, I understand the use of @ for inheriting sections, and parents, but the one I can never really get through my head is this one:
[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'

I see this used in all sorts of projects. Despite the description given above, the @ symbol seems to be more a way of mashing two sections together that are usually seperate.

For example, where you would have:
[MyObject]
Graphic = MyGraphic

[MyGraphic]
Texture = my-texture.png

You can somehow mash them together using a @?:
[Object]
Graphic = @
Texture = my-texture.png

Is this the idea?

Comments

  • edited April 2016
    In effect, yes, albeit simply mashing two section together can be done manually.
    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:
    [MyObject]
    Graphic = @
    

    Translates to:
    [MyObject]
    Graphic = MyObject
    

    Which you could have written yourself explicitly. However, if you now consider this "child":
    [MyChildObject@MyObject]
    

    In this case, @ morphs into the child's section name, so it would be like having typed:
    [MyChildObject@MyObject]
    Graphic = MyChildObject
    
  • edited April 2016
    Cool so I do get it now. But the way it is described is confusing.

    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.
  • edited April 2016
    I'm fine with saying that the value indicates the current section, or whichever way you prefer formulating it. However the "where to source the data from" part is not always correct.
    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:
    [MyObject]
    MyValueOnlyIKnowHowIMGoingToUseIt = @
    

    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:
    [MyObject]
    Graphic = MyObject
    SoundList = MyObject
    ShaderList = MyObject
    
    [MyChild@MyObject]
    Graphic = MyChild
    SoundList = MyChild
    ShaderList = MyChild
    
    etc, instead of having separate sections all the time.
  • edited April 2016
    That last example you gave, I would call section inheritance, which is the technique I use pretty much everywhere.

    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.
  • edited April 2016
    sausage wrote:
    That last example you gave, I would call section inheritance, which is the technique I use pretty much everywhere.

    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:
    [MyFX]
    SlotList = MyFX
    
    [MyText]
    Text = MyText
    

    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:
    
    [MyDefaultSection]
    Graphic = @
    SlotList = @
    KeepInCache = true
    
  • edited April 2016
    Ah right, the default section.. yes haven't looked at that yet, but as I read it, ir can be defined (and in this case) with:
    [Config]
    DefaultParent = MyDefaultSection
    

    @:
    [MyObject@@]
    
Sign In or Register to comment.