Config Subsections proposal

[enobayram]

Hi! Regarding our discussion about the orx "subsection"s:

The idea was:

[MyObject]

Graphic.Text.String =  Hello, world!

Sound.Music = traviata.ogg

would be expanded to:

[MyObject]

Graphic = MyObject.Graphic

Sound = MyObject.Sound

[MyObject.Graphic]

Text = MyObject.Graphic.Text

[MyObject.Graphic.Text]

String = Hello, world!

[MyObject.Sound]

Music = traviata.ogg

There are two things I'd like to open for discussion here; 

1) Composite Objects

in response to this proposal, I asked whether we can extend this proposal to also be useful for composite objects:

If I have a composite BoardA containing TextA:

[BoardA]

Content = TextA

[TextA]

Graphic = @

Text = @

String = This is text A

And I want to derive a "BoardB" from this which only differs in it's "Content"'s text, right now I need to write:

[BoardB]

Content = TextB

[TextB@TextA]

String = This is some other text

But similar to the proposal, I'd like to just write:

[BoardB@BoardA]

Content.String = This is some other text

At the time, we weren't able to come up with a way to achieve this, but I think I may have a solution. What we could do is when you write the above BoardB in config, similar to iarwain's proposal it gets expanded to:

[BoardB@BoardA]

Content = BoardB.Content

[BoardB....@BoardA.Content]

String = This is some other text

I.e, the newly craeted BoardB.Content section inherits from whatever the "Content" field contained before.

2) Back References to Parent

This issue is independent of my composite object extension, so the issue exits for both cases. What happens when the user enters:

[MyObject]

SomeField = ABCD

Graphic.Text.String =  @.SomeField

Will this work? If it does; how about this:

[MyOtherObject@MyObject]

SomeField = EFGH

Will MyOtherObject's Graphic's String refer back to MyOtherObject's Somefield?

I know this brings a lot of complexity, and the answer might legitimately just be "no", but if it ends up being "yes" it'll bring a lot of flexibility. You can for instance pull off a trick like this in pure config:

[RabbitJumpAnim]

Texture = rabbit.png

KeyData1.Texture = @.Texture

KeyData1.TextureSize = (50,50,0)

KeyData2.Texture = @.Texture

KeyData2.TextureSize = (50,50,0)

KeyData2.TextureCorner = (50,0,0)

...

If the answer is "yes", you can do:

[FrogJumpAnim@RabbitJumpAnim]

Texture = frog.png

Needless to say, such a flexibility helps composite objects a lot too.

[enobayram]

I have another config extension proposal:

As you know, we can execute orx commands during the loading of a config file with

% command args

syntax. Even though this syntax can be used to make rather complicated config arrangements that couldn't otherwise be expressed with config alone, it has the weakness that any future changes to config sections will not be reflected to the result of that command. My proposal aims to solve this with a similar additional option:

[SomeSection]

SomeValue %= command args

and the command gets executed every time SomeValue is accessed.

[iar...@orx-project.org]

Sorry, I'm still internally debating on that one, I haven't forgotten. =)

I'll try to find some time to think about it in december, when I'll have a bit more spare time!

--
You received this message because you are subscribed to the Google Groups "orx-dev" group.
To post to this group, send email to orx...@googlegroups.com.
Visit this group at http://groups.google.com/group/orx-dev.

[Enis BAYRAMOĞLU]

No problem, this would be a very useful feature for me, moving a lot of code from C++ to config, but it has no urgency. I also reckon that the feature is both practically and conceptually non-trivial. It might lead to dead ends.