On 30/03/15 23:10, Peter Ansell wrote:
All of the BlankNode's in the Triple that was added may be internally
remapped during the add operation. Hence, the .equals will change when
the remapping occurs. Returning the mapped values enables a user to
get access to that information.
Removing the return value is fine with me if it can't be supported in
a performant way. It just removes the simple way for a user to know
what BlankNode remapping occurred.
Peter,
Great - and I see the change in git.
A simpler example would have been a parser not wanting to use the return
from add() and an implementation that does not store Triple objects, but
has data structures using the subject/predicate/object directly.
Returned triples are just object churn albeit probably quite efficient
churn.
(hmm - interesting - so once mapped, the mapping is stable.)
Andy
On 31 March 2015 at 06:46, Andy Seaborne <[email protected]> wrote:
- void add(Triple triple);
+ Triple add(Triple triple);
Returning something from add() does not work for me.
(And even if it did, I would have expected "boolean" as to whether the
triple was actually added or not.)
1/ I don't understand "possibly mapping" being in the API. A triple is a
triple. What is the client supposed to do differently with .equals one
returned (it is .equals?)
2/ I am finding that having a flow back from add operations difficult to
deal with.
A sequence of add(Triple) can be batched up and only need to be performed
before another operation is called that can observe the change.
In the case a remote destination, the overhead per add is significant
(network rounds). But if it is delayed, then the return of anything is not
available.
For a general interface, this should be
void add(Triple)
Andy
