On Tue, Apr 14, 2015 at 9:43 PM, Christopher <[email protected]> wrote:
> Well, it depends on the behavior of the iterator beneath it. Most > iterators would probably not want to copy, for performance reasons, but an > iterator could choose to break that convention (or may need to). It is kind > of unintuitive that a developer would need to understand the behavior of > the iterator beneath it, so a best practice is probably to just copy inside > your iterator, if you need a copy. > > I know we've discussed trying to revamp the iterator API before, so if you > think there's something we could do to make this a bit more intuitive, > that'd be very welcome and appreciated. > Random thought on revamp. Immutable key values with enough primitives to make most operations efficient (avoid constant alloc/copy) might be something to consider for the iterator API > > On Tue, Apr 14, 2015 at 8:57 PM Dylan Hutchison <[email protected]> wrote: > >> While debugging a custom iterator today to find the source of a logical >> error, I discovered something an iterator developer may not expect. The >> getTopValue() of RFile returns a reference to the RFile's internal Value >> private variable. The private variable is modified inside RFile via >> >> >> val.readFields(currBlock); >> >> >> which means that if an iterator stores the reference from getTopValue(), >> that is, without copying the Value to a new Object, then the value will be >> updated in the iterator when the RFile's next() method is called. >> >> Here is an example snippet to demonstrate: >> >> Value v1 = source.getTopValue(); >> >> source.next(); // v1 is modified! >> >> >> The following code would not have a problem: >> >> Value v1 = new Value(source.getTopValue()); >> >> source.next(); >> >> >> I bet this is done for performance reasons. Is this expected? >> >> Regards, Dylan >> >
