On Monday, 1 August 2016 at 07:38:29 UTC, Guillaume Piolat wrote:
On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta wrote:

kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI.

Okay, just wanted to know what we are buying with (supposedly) more code. For reference I was speaking of the D kxml package, which is a DOM parser than can range-iterate on nodes using XPath.

Ouch. Looks like I misunderstood you then. I apologize.

I don't know anything about that D package, but I can safely assume that this library will provide more functionalities and (most of all) more customization points. It's designed as a collection of components, each of with can be customized or even substituted with a user defined one. This is what such a big quantity of code will buy.

There are various principles one can use when building a library. In this case I didn't choose minimality. I prefered extensibility and customizability.

Reply via email to