Re: [Wesnoth-dev] WML Framework
Moderator: Forum Moderators
Re: [Wesnoth-dev] WML Framework
Since I am not able to post to the #wesnoth-dev mailing list, and GNA refuses to do anything about it, I am responding to Yogi's email on this forum instead.
------------------------------------------------------------
I think your proposal overlooks some critical features of the vconfig (vconfig means "variable" config).
Your approach would force it to be non-variable. Vconfig usage is expanding and we plan to put it more places. Eventually, all ScenarioWML should support it, except for certain keys such as mapdata.
Another problem, what about "empty" keys ? Would you need a boolean + t_string for some keys to track the value, and whether or not it was set ?
A few more details about the vconfig:
1) vconfig allows you to insert normal scalar values from variables
2) vconfig allows you to insert scalar values from array variables
3) vconfig allows you to insert members from auto-stored variables which use lazy evaluation
4) vconfig allows you to insert tags from array variables
(see the [insert_tag] documentation)
You can't substitute the variables in advance, since they may change by the time they are needed. In fact, you can't even do validation of tag names in advance, since we plan a [set_function] feature which will allow you to assign behavior to unused tag names.
So basically, the strategy you are envisioning is wholly insufficient for all of game_events and filters, and eventually all scenarioWML. But, the good news is, this makes WML very powerful for UMC authors (and it keeps the LUA proponents at bay).
Don't get me wrong, I agree that MANY C++ objects should be fully constructing themselves instead of hanging onto their config trees. In some cases, however, you really want to hang onto a config tree; if it's a vconfig, even more likely. I don't see why you couldn't have hybrid objects that are fully constructed from their config, then discard it, then additionally know how to handle certain vconfig arguments to certain methods. A good example would be the unit class.
------------------------------------------------------------
I think your proposal overlooks some critical features of the vconfig (vconfig means "variable" config).
Your approach would force it to be non-variable. Vconfig usage is expanding and we plan to put it more places. Eventually, all ScenarioWML should support it, except for certain keys such as mapdata.
Another problem, what about "empty" keys ? Would you need a boolean + t_string for some keys to track the value, and whether or not it was set ?
A few more details about the vconfig:
1) vconfig allows you to insert normal scalar values from variables
2) vconfig allows you to insert scalar values from array variables
3) vconfig allows you to insert members from auto-stored variables which use lazy evaluation
4) vconfig allows you to insert tags from array variables
(see the [insert_tag] documentation)
You can't substitute the variables in advance, since they may change by the time they are needed. In fact, you can't even do validation of tag names in advance, since we plan a [set_function] feature which will allow you to assign behavior to unused tag names.
So basically, the strategy you are envisioning is wholly insufficient for all of game_events and filters, and eventually all scenarioWML. But, the good news is, this makes WML very powerful for UMC authors (and it keeps the LUA proponents at bay).
Don't get me wrong, I agree that MANY C++ objects should be fully constructing themselves instead of hanging onto their config trees. In some cases, however, you really want to hang onto a config tree; if it's a vconfig, even more likely. I don't see why you couldn't have hybrid objects that are fully constructed from their config, then discard it, then additionally know how to handle certain vconfig arguments to certain methods. A good example would be the unit class.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."