std.experimental.xml available on DUB
Lodovico Giaretta via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Aug 1 05:40:48 PDT 2016
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.
More information about the Digitalmars-d-announce
mailing list