More importantly on this and similar issues is where it makes sense for the support of things like XML to be.

As you quite rightly pointed out, KiXtart can interface with COM automation quite successfully with a couple of notable exceptions.

This has two major benefits. Firstly, there only needs to be one implementation for the support of a feature.

If you take XML as an example, would you expect the coders of Word, Excel, Internet Explorer and so-on to write their own XML parsers and handlers? Of course not, it would be mad. Instead a library is developed, the API is published and any application which needs XML parsing uses the library.

The second major benefit of doing this ways is about who maintains the code. Is it really a good idea for Ruud to have to add massive complexity to KiXtart for something which is at present of limited need just to make the interface simpler? Something that he may well not have expert knowledge in.

No. It is much better for the XML experts to maintain, bug-fix and enhance the XML support libraries.

Ruuds time is better spent developing the core of KiXtart and adding features which enhance the scripting language, rather than adding functionality which is already available.

As a guide, I usually review enhancement requests and fit them into loose categories:
  • Very Good This is something which would benefit most people, but more importantly is it something which can only be achieved by a change in the scripting language. Some examples are static variables, pass by reference, input/output redirection and support for binary data.
  • Good Again, most people would benefit. These are requests which would provide support for facilities which can already be handled by UDFs and COM but should probably be part of the core language. Things like mathematical functions, date handling, pattern matching, associative (hash) arrays.
  • Not so good This category is for those things which don't really belong in KiXtart. It may be because they are so esoteric that very few people will use the feature. More often it is because the feature is available by another method such as via the COM automation and it is appropriate for it to remain that way. Examples of this are network (socket) programming, HTTP, Email, database and LDAP.


Not everyone will agree with me, but I think that XML support sits quite firmly in the last category.