Talk:Settings Proposal

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)