Refactor the `Triple` variant of `Subject` and `Term`
Subject and Term both have a variant that goes:
Triple(&'a Triple<'a>)
I am extending Sophia to use [TriplesFormatter], and I find the above very inconvenient. Everytime I want to create a Subject or Term "view" of my internal terms, if that term is a quoted triple, I need to allocate a Rio Triple somewhere that I can then reference. And I have to do this recursively, which is a pain. (I was unable to achieve that without some unsafe code...)
Did you run into a similar problem with Oxigraph? Did you find an elegant way to solve it?
I would suggest to change the variant in Subject and Term
Triple(Box<Triple<'a>>)
I think that the code of the parser would be minimally impacted by that change, and it would make it much easier to use the formatters.
If you agree with the general idea, I can propose a PR.
Did you run into a similar problem with Oxigraph? Did you find an elegant way to solve it?
Yes, I ran into a similar problem and I have not found a way to elegantly solve it. I use Triple(Box<Triple<'a>>) just like you suggested inside of oxrdf.
If you agree with the general idea, I can propose a PR.
Yes, feel free to do so.
Just gave it a quick try, but unfortunately, this change is much more disruptive than I anticipated...
- if we go that way,
SubjectandTermcan not implementCopyanymore, - so
TripleandQuadcan't implementCopyeither, - but the whole API assumes that
TripleandQuadare copy, because theon_triplemethod passed toTriplesParserexpects aTriplepassed by value, not by reference (and similarly forQuadParser).
This would force implementation of TriplesParser to clone the triple before passing it to on_triple, possibly causing recursive clones of the boxed quoted triples, which would go against all the optimizations done by Rio for atomic terms...
Thank you for trying!
I am moving forward well with my new N3/Turtle/N-Triples parser. It seems to be at least twice as fast as Rio. So, if you are fine to wait a bit I hope to release it in the next few month.