Background: working on a replacement for std.xml. Designing the
DOM API.
Of course, I have to provide a way for the users to use a custom
allocator for the DOM objects.
But the DOM, as described in the official docs[1] (and as I would
like to have it), shall be pluggable: many implementation may be
available, and the user can ask for one that provides the
extensions ("features" in the DOM spec) that he needs. This kind
of OOP, with various implementation providers, does not work well
with templates, so the "D way" of having a template parameter for
the allocator is quite complex and ugly.
The "standard DOM way" of dealing with any additional thing (as
is the allocator selection) is to use hasFeature/getFeature; this
are standard OOP interface methods, so the work very very well
with IAllocator, thus allowing an easy, straightforward solution.
But this solution is not @nogc (as IAllocator has no information
of what the underlying implementation is).
So my question is: which solution should I use:
1) a template based solution, which for this problem looks like
an hack, so then I can say "Phobos provides a full DOM Level 3
implementation that works in @nogc code"
2) a standard OOP solution, very DOM style, but then I have to
say "Phobos provides a full DOM Level 3 implementation that does
not use the GC, but cannot be marked @nogc; if you don't trust
me, check the profiler"
Thank you in advance for your help on this matter!
