On Fri, Nov 30, 2018 at 7:10 PM Lukasz Cwik <lc...@google.com> wrote: > > Uh, I'm not sure what your asking.
I'm asking why we wanted a markDone in the first place. > The SDF API already has a void return on processElement means that a call to > tryClaim must have returned false We could widen this to "or finished the restriction." > while a non void return allows the caller to either return STOP (tryClaim > must have returned false) or return RESUME (with a time of when to resume). We could also return STOP if tryClaim never returned false but the restriction was finished. > This allows the framework code to prevent user errors by ensuring the > restriction has been completed. I don't think the framework can ensure this. (It can enforce the above constraints that on a STOP tryClaim did indeed return false on the last call, but I'm fuzzy on the value this actually provides when it just means the use must artificially force it to return a false value. It also means we can't make it an error to try claiming values outside the initial restriction. If we want to make things more explicit, we could require a STOP or RESUME return rather than allow a void return.) Maybe I'm just not clever enough to come up with a kind of source where this could be good at catching errors? > Also, "" is the byte key range, the code could have just passed in > range.getEndPosition() in to the final tryClaim, its just that "" is > shorthand and would be similar to passing in Long.MAX_VALUE for the file > offset range. Having to choose a value pass depending on the restriction tracker type is something that could simply be eliminated. > On Fri, Nov 30, 2018 at 2:45 AM Robert Bradshaw <rober...@google.com> wrote: >> >> In looking at the SDF examples, it seems error-prone to have to >> remember to write >> >> tryClaim([fake-end-position]) >> >> to indicate that a restriction is finished. IIRC, this was done to >> decide whether the entire restriction had been processed on return in >> the case that tryClaim never returned false. It seems preferable to >> encode this into the return value (with a void return meaning iff >> tryClaim returned false, and a non-void return being able to indicate >> any hints as to when, if ever, process should be called again). >> >> Can someone job my memory as to if there was a case in which this wouldn't >> work?
