I think the primary advantage of an OO style is organization. I'm working on a new small mod I'll try this method as an exercise. It didn't take long to understand the syntax. Unfortunately it seems to have limited application to the xml. One of my most recent mods has less than 100 global names created in the lua "side", but over 200 global names created on the xml "side":
<Button name="MyButtonTemplate" virtual="true">
<Layers><Layer level="ARTWORK">
<Texture name="$parentIcon"/>
<FontString name="$parentName"/>
<FontString name="$parentData"/>
</Layer></Layers>
</Button>
<Button name="MyButton1" inherits="MyButtonTemplate"/>
<Button name="MyButton2" inherits="MyButtonTemplate"/>
<Button name="MyButton3" inherits="MyButtonTemplate"/>
The above creates 12-13 global names. When dealing with scrollbars and stuff it adds up fast. Ironically the above seems to be OO in concept but it doesn't help the namespace at all.
|
In fact, I'm sure this must have a resource hit somewhere because everything needs to traverse the namespace and it's like the directory of a hard-drive. On a hard-drive, if you keep things in one folder only, if you kept all your files there, the hard-drive is faster and defragments less quickly. However, as your file structure gets infinitely more complexe and strews about, your hard-drive becomes far more quickly fragmented.
|
hehe I read that as an argument against OOP. Replace "folder" with "table." I'm not against OO at all and like the idea, nor do I feel that there is a "crusade" to make everyone do stuff in one way. But just to play devil's advocate to learn more: What is resource? Is it performance (clock cycles), memory space, the stack?
Allocated memory for tables grow semi-exponentially in lua. It can be argued that a more "flat" namespace will exist more compactly in memory. Think of how many M&Ms you can put in a jar with and without the wrapper. Strings and tables exist as references within the table, but the shocking table growths I saw in Recap showed a serious footprint growth to complex tables. Moving a table of 100 combatants with full details (too much detail heh) would go from 1mb to 50k by collapsing it from a complex table to a "flat" table of strings. (edit: to be fair the flat tables were compressed somewhat but the difference floored me)
While it's obvious that local lookups are faster than global which are slightly faster than global table lookups, I'm inclined to believe that less stuff in the global namespace may eventually help performance because as the global namespace gets really large then the first lookup will exceed table lookup. But where that "really large" threshhold happens I'm unsure of, or if it's practically achievable with mods. Is there a way to scan the global namespace to see how many global names there are? That would be an interesting study: to determine how many names in the namespace (including blizzard's default UI) it would take before it takes longer to do a global lookup than it takes to do a table lookup with the default UI and one non-default global name.
I liken the WoW UI sandbox to the old DOS/Win3.x days with the 640k memory limit. For large projects there are definite advantages to organization that's worth a little overhead. And of course I'm sure the ease of doing things sloppily in a non-OO way eat up the performance/memory gains. Personally I think the liberal use of localization files that add hundreds of globals is a greater crime than doing mods the same way blizzard does but that's another topic. :p