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.
