Quote:

---

Since I don't believe that's what you're saying then it comes back to a completely arbitrary decision as to what is included and what is not. So, it really sounds like you're saying not that the language shouldn't support anything that is available via other means but rather you don't think this particular function should be included.

---

Yes, that's pretty close

There are people using well known stuff like IE COM, Office COM and KiXforms as well as more obscure objects. Adding KiXtart functions to access all of this functionality would be ridiculous.

That's why I said that there should be a balance - it's only arbitrary in that Ruud as the arbiter will determine whether it does KiXtart more good than harm in including it, whether the number of people who would use it warrants the effort to include it, and whether it is supportable going forward as the underlying protocols are enhanced.

XML is an order of magnitude more complex than INI file layout. Simple READ/WRITE functions are not sufficient to support the complexity, so my major concern is that support is not bifurcated.

If the end result is some XML files are read/writeable and some not or some XML functionality is available but some not or new functionality provided by XML enhancements cannot be accessed in KiXtart then scripters will need to disregard the built-ins and revert to COM to provide the functionality. This is already happening in a number of areas where the scripters needs are not supported by the built-in functions and we are having to find other methods and it lessens KiXtart.

Quote:

---

And on that point I don't think we'll ever agree.

---