Talk:Settings Proposal: Difference between revisions
mNo edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute? | I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute? | ||
Also, how about just exporting settings as key-value pairs under a global "settings" table in the resources' VMs? No set/get is required that way provided that you could update the vars' values for all VMs simultaneously after an assignment. If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption. | Also, how about just exporting settings as key-value pairs under a global "settings" table in the resources' VMs? No set/get is required that way provided that you could update the vars' values for all VMs simultaneously after an assignment. | ||
There's a major advantage to this method: since scripters will be using the settings table directly, any change will instantly apply. Using get/set, scripters would be likely to store the settings on load and a resource restart would be necessary. | |||
If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption. | |||
--[[User:Jbeta|jbeta]] 06:41, 7 September 2007 (CDT) | --[[User:Jbeta|jbeta]] 06:41, 7 September 2007 (CDT) | ||
Revision as of 11:50, 7 September 2007
Suggestions
I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute?
Also, how about just exporting settings as key-value pairs under a global "settings" table in the resources' VMs? No set/get is required that way provided that you could update the vars' values for all VMs simultaneously after an assignment.
There's a major advantage to this method: since scripters will be using the settings table directly, any change will instantly apply. Using get/set, scripters would be likely to store the settings on load and a resource restart would be necessary.
If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.
--jbeta 06:41, 7 September 2007 (CDT)