On Jan 19, 2012 11:02 PM, "Daniel Shahaf" <danielsh_at_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 <danielsh_at_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
Received on 2012-01-20 07:43:42 CET