[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r15370 - in branches/python-bindings-improvements/subversion/bindings/swig: python/libsvn_swig_py python/svn

From: David James <james82_at_gmail.com>
Date: 2005-07-20 22:13:14 CEST

On 7/20/05, Philip Martin <philip@codematters.co.uk> wrote:
> David James <james82@gmail.com> writes:
> > David James wrote:
> >> To make my code more clear, I propose to take the following steps:
> >> - Rename the _global_pool variable to svn_swig_application_pool
> >> throughout the SWIG bindings (including in the Perl and Ruby bindings)
> >> - Add a comment to the source code explaining why I created a global variable.
> >>
> >> Philip, does this sound like a good solution?
> I didn't really understand the explanation.
Would a more thorough explanation help?

If not, I'll just switch to your suggested variable name. I think
either "svn_swig_pool" or "svn_swig_py_pool" would be good names.

> > Oops. svn_swig_application_pool is a bad name for the variable,
> > because it is not only an application pool -- we are forced by
> > implementation details to use the same name for local pools. Would the
> > name "svn_swig_pool" be better?
>
> Is the pool Python specific? svn_swig_py_pool might be better.
All the code which currently uses this application-level pool is
Python-specific. Nevertheless, we also define function-level pools in
all three languages, and these pools use the same variable name. I
think that this consistency is a Good Thing, because, with consistent
variable names between bindings, we can (theoretically) write code
which works with all three sets of bindings.

It's not often that it is possible to reuse the same code for
different sets of bindings, but when it is possible, it helps reduce
maintenance costs.

So, to summarize, I'm leaning towards using the name "svn_swig_pool".

Cheers,

David

-- 
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 20 22:14:23 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.