www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nogc vs IAllocator

reply Lodovico Giaretta <lodovico giaretart.net> writes:
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!
Jul 16 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
I have no idea why anyone would prefer IAllocator approach to 
efficient and inline-able template based version. I doubt 
template bloat from dozens of different allocators in one project 
is realistic concern for std.xml
Jul 16 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
And of course I forgot to link the relevant documentation...
[1] 
https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html


 I have no idea why anyone would prefer IAllocator approach to 
 efficient and inline-able template based version. I doubt 
 template bloat from dozens of different allocators in one 
 project is realistic concern for std.xml


I was not thinking about template bloat. I was more concerned 
about how to mix it with the possibility of multiple 
implementations provided by different libraries. Conceptually one 
should use a method getDOMImplementation("list of features") and 
get a list of all implementations supporting those features that 
are linked in the binary. How should this become? 
getDOMImplementation!AllocType("list of features", allocator)? 
And in this case, how shall this method retrieve all available 
implementations from imported modules? Without templates this 
would be as easy as a module initializer that registers the 
implementation in a global list. With templates everything must 
be resolved at compile-time, and I fear that this may require 
some big hack.
Jul 16 2016
parent reply Dicebot <public dicebot.lv> writes:
What kind of features do you mean? I'd personally want only 
compile-time configuration and minimal to no OOP.
Jul 16 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Saturday, 16 July 2016 at 18:34:31 UTC, Dicebot wrote:

 What kind of features do you mean? I'd personally want only 
 compile-time configuration and minimal to no OOP.


Thank you for your time.
The DOM specification provides "DOM features"[1] as a mean to 
extend the DOM with custom informations and methods, so that you 
can query a node at runtime if it supports a certain "feature". 
If it does, it will return you an interface that provides access 
to those infos and methods (usually that interface is just a 
dynamic cast of the object itself, but it is not mandatory). For 
example, an implementation may provide methods to modify SVG 
nodes in a more meaningful way than dealing directly with parents 
and siblings. You would access these extra methods using 
getFeature("SVG"). The W3C itself maintains a long list of such 
optional extensions [2].

[1] 
https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMFeatures
[2] 
https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html#ID-Conformance
Jul 16 2016
parent Dicebot <public dicebot.lv> writes:
Oops, this looks like dark side of XML spec I wish I have never 
learned about :X Sorry for irrelevant comment.
Jul 16 2016
prev sibling next sibling parent The D dude <thedlangdude gmail.com> writes:
On Saturday, 16 July 2016 at 17:46:12 UTC, Lodovico Giaretta 
wrote:

 Background: working on a replacement for std.xml. Designing the 
 DOM API.

 [...]


Another problem that you soon will encounter is that your 
templated can never be  safe, nothrow or pure again - even if you 
use the GCAllocator for simple stuff like allocating arrays.

In case you get frustrated about this, you should vote for this 
PR:

https://github.com/dlang/phobos/pull/3891
Jul 16 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sat, 16 Jul 2016 17:46:12 +0000, Lodovico Giaretta wrote:

 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"


With templates, you have XmlParser!IAllocator, allowing you to use a 
runtime-defined allocator, and XmlParser!Mallocator, which is implicitly 
 nogc. Right? Or am I missing something?
Jul 17 2016