On Jan 19, 2012 11:02 PM, "Daniel Shahaf" <danie...@elego.de> wrote: > > Hyrum K Wright wrote on Thu, Jan 19, 2012 at 21:47:51 -0600: > > On Thu, Jan 19, 2012 at 8:40 PM, Daniel Shahaf <danie...@elego.de> wrote: > > > I do wonder if the "to disk" threshold should be in the public > > > signature, but don't have offhand a use-case justifying that. > > > > We could, but I figured callers who needed finer-grain control over > > the size of the buffer would use the underlying private API which > > gives them that ability. And as I noted in the code, the choice of > > 100k was completely arbitrary, the result of a lot of squinting and > > hand waving. If somebody has better guestimates (Stefan F.?) as to > > what would be better, feel free to improve upon it. > > FWIW, my point was that the caller (of this now-public API) may be able > to have a better guesstimate as they'd know the use-case, the number of > concurrent spillbuf objects, the typical length (`wc -c`) of the stream, > etc.
Right. We always assume "caller knows best", and we try to document our APIs to give them the needed info. I would recommend exposure, with two DEFAULT constants. I'd be -0 with making them 0 and documenting their remapping to "suitable defaults". (ie. allowing callers to use 0 instead of a 20-char symbol) I'm also a bit concerned with putting these in the public API. I guess our prevalence of streams kind of demands this "memory shortcut", but I worry about doing this earlier rather than later. Maybe delay one release? (I'm confident in the code; unclear on what we want to sign up for long-term) Cheers, -g
