Re: svn commit: r1705060 - in /subversion/trunk/subversion/libsvn_ra_serf: ra_serf.h serf.c util.c

Ivan Zhakov wrote:
> As far I remember this thread about two pools paradigm itself
> (result_pool and scratch_pool). It's not about making all functions
> follow two pools paradigm.

Correct.

> Some of API introduced in 1.9 doesn't
> follow this paradigm for some reason.

Yes, I see that.

> Please understand me correctly:
> I really like two pool paradigm, but sometimes it's not necessary,
> especially for local helpers.

OK, you have partially convinced me. For a simple local function, we
might not want to take two pools when that seems unnecessarily
verbose. If this function takes one pool, allocates its result in that
pool, and perhaps allocates a small amount of temporary data as well,
I accept your argument that we don't necessarily want to name the pool
'result_pool' because that could be confusing in places where its
implementation is storing scratch data. In cases like this I agree we
may want to use the name 'pool'. And in other cases there is
flexibility too. We don't enforce a rigid rule.

- Julian
Received on 2015-09-25 12:55:27 CEST