Quote:
The best compromise would be if Ruud added functions that simply called the APIs directly. That however adds no real benefit over loading an XML UDF library at the top of a script with your own ReadXML() and WriteXML() functions to call the APIs.
And I certainly understand the concern about duplicating existing functionality and I would agree that it should definitely be avoided wherever possible. But that leads back to my original question. Since existing libraries are available for most all of the current kixtart functions are you suggesting that those should be deprecated in future versions? Or are you saying that functions that are already included in the core language should stay and nothing new should be added where COM functionality exists? I'm not trying to put words in your mouth, I just don't understand how some duplicated functionality is OK and the rest is not.
The real value of KiXtart to me has always been that it contains core functionality that reduces my need for COM reliance. If the evolution of KiXtart is moving towards tighter COM integration with nothing new added to the core language then I would say it has no real benefit over VBScript. If most or all of my scripting tasks will require COM then what value does KiX have over VBScript? I really can't think of any except situational reasons (my company doesn't allow WSH on the desktops, etc.)
What draws most new users into KiX as a scripting tool is that it contains a large number of functions that don't require COM. For someone that has never scripted before, figuring out "that COM stuff" can be quite daunting. But, for example, as the IT community evolves from ini to registry to xml configuration (and I'm not inviting a flame war over which is "better") it would be nice for KiXtart to evolve with it in ways that VBScript can't or won't.
Edited by Stevie (2005-11-30 07:26 PM)
_________________________
Stevie
