On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote:
On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta
I'm proud to announce that std.experimental.xml v0.1.0 is
available on DUB !
This is the project I'm working on for GSoC 2016. It aims to
become a substitution for Phobos std.xml. Now you can easily
try it and provide some feedback. I will soon create a WIP PR
on the Phobos repository.
I suggest you to depend on ~master instead of v0.1.0, as
bugfixes and enhancements are added on a daily basis (v0.1.0
is already one commit behind!)
1) The documentation  is very limited;
2) Some advanced DOM methods are not completely implemented;
3) Some advanced features (e.g. DTD validation, namespace
checks) are not yet available.
If you find any issue / have any suggestion, please file an
issue on Github .
I have two comments.
What is the plan for the string interner and the
allocator-based appender ?
They are neither part of the package, nor proposed in phobos,
it seems that you'll encounter a problme in the package
structure itself. This is also problemtaic now if I want to
test it I have to add 3 import paths to sc.conf.
I suggest you either to propose them for phobos or to add them
in a subpackage "internal" **inside xml** (or in a big
internal.d module) like it's done for several phobos packages
I see a naming problem in you "fast" strings: fastIndexOf,
This is not good: does it mean that phobos's equivalent are
slow ? Does it mean that you'll also propose slow equivalents
(This is absurd, but it shows the problem).
Thank you for your comments.
Talking about your points:
1) the interner shall really go away before inclusion in Phobos;
it is unneeded; its code is already partially duplicated in
CopyingCursor (std.experimental.xml.cursor); but it would be good
to have something like this in Phobos, somewhere in the future.
2) The appender is needed, as the Phobos one does not work with
custom allocators; I don't have the time to polish it for Phobos
adoption, so putting it in an internal xml submodule may be a
3) The fastXXX functions are intended for internal usage; they
will have package protection in the final library (I really
forgot about this thing; thanks).
I will tag v0.1.1 late this night, with some fixes based on the
feedback from you and Steven.
Thank you again.