If COM is so much better than native support, then why doesn't Ruud drop support for mapping drives, mapping printers, file i/o, registry i/o, and pretty much everything else KiX does. After all, all of that functionality is available via COM as well. And if that really is the preferred way to interact with the system then there is no need for internal support of these other functions either.
Of course I'm being a smart ass. But as I've maintained for a long time, what makes KiX as popular as it is has to do with so much functionality built into the core language. The best example is getting an environment variable from KiX and VB. In Kix, %var% is all it takes. In VBScript, you need multiple lines of script just to get the variable.
I think we can all agree that if the core language allows you to do a job in fewer keystrokes, and more intuitively, then that is the better option. What really is the decision point between what gets left in and left out is the level of complexity of the feature, how much larger the interpreter will become, and ultimately, if Ruud wants to support it or not.
As to the XML question in particular, it certainly wouldn't be practical to redesign the complete XML DOM. It's a very comprehensive structure and COM is more than adequate to handle those types of tasks. But for the simpler reads and writes (that don't return an array of nodes, for example) it seems that readxml() and writexml() would be ideal kix functions to complement the existing ini, registry, and file read and write operations. Simple functions wouldn't be too complicated to implement and wouldn't bloat the interpreter. So the only question is does Ruud want to do it or not? And as he's been quiet on this topic as its come up before, my magic 8-ball says "All signs point to NO". But we can always hope.
_________________________
Stevie
