[Rowne]

Well, all this is chopped down by Ace and AceGUI I'd note (by using a base framework to load only one XML set). XML is irrelevant in Ace AddOns and even with a GUI, if AceGUI is used then the XML is minimal at best (I chopped a near 300-line XML file down to 12 lines in FuncBook). If we're talking about Ace then the XML doesn't even come into the equation, other than Ace's XML which is but one AddOn compared to the many which now support it. Hm, so the outcome of this is that OO works better with a framework to lessen the XML load (such as Ace).

What I'd like to try myself next is to run these tests with a purely Ace(D) AddOn with no XML to see how that compares. If OO alone isn't good enough because of the XML overhead then perhaps the methods I've adopted currently are the best ones for the environment. That's really what I was curious about here, how much of it is OO and how much is Ace. The end result seems that OO is one part of a good thing whereas Ace is the other and they go well together.

---Edit---

In case the point on XML isn't clear; XML only generates extra globals through incorrect use. For example, if you were to use AceGUI and then put all elements in a '$parent' system, then I believe only the main element is global and then the '$parent' name elements are subelements withint he global element's environment. So for example ...

BlahFrame
BlahFrameText

This would be two global elements.

BlahFrame
$parentText

This would be one global element of BlahFrame with a subelement of Text inside it. I need to do more research to provide proof to that however.

And with the overall size of XML and the variables within, as I said, Ace and AceGUI cut down on that or make it non-existant.