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. 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 > >
