So, there are some "action items" contained in this little exchange.
Let's clear up the other ones:
- naming schemes -- do we agree that the old fs.py renaming stuff
sucks, so go back to using the full function names?
- headers-to-modules ratio -- we'd like to see each header
handled by its own module, right?
Are there other changes of interest that I'm forgetting?
Philipp von Weitershausen <philipp@weitershausen.de> writes:
> cmpilato@collab.net wrote:
> >>>* Makefile.in
> >>> Do not call SWIG with the -noproxy flag: build shadow classes
> >>> instead of accessor functions for structs.
> >>>* subversion/bindings/swig/*.i
> >>> This makes the provided python modules in
> >>> subversion/bindings/swig/python/svn obsolete because SWIG needs to
> >>> create its own. Thus included the additional code from the now
> >>> obsolete modules in the SWIG macros using the %pythoncode directive.
> > You're referring to obsolete modules, yet you've not removed anything
> > from version control. I'm guessing you're code is meant to get rid
> > of subversion/bindings/swig/python/svn/*.py.
>
> Exactly. I guess I forgot to write a log message for that.
>
> > There's only one thing I'm not very fond of, and that's the
> > %pythoncode {} blocks which now house the old contents of the *.py
> > wrapper scripts we had.
>
> Yeah, I agree, it's ugly.
>
> > The other is to keep our bindings pure, with _fs.so and fs.py, and
> > then any wrapper code we do lives in modules with names like
> > FileDiff.py, WorkingCopy.py, etc.
>
> +1 here. For example, I already have some code that wraps all
> functions in svn_client.h (checkout, import etc.) in a class. This
> could go into Client.py, as much as a class wrapping all working copy
> functions would go into WorkingCopy.py.
>
> > I guess what I'm getting at is that it's yucky to have our .i files
> > growing into these massive sourcefiles with concatenating
> > language-specific wrapper code for python, perl, java, ruby, etc. just
> > slapped into %python-et-all-code {} blocks.
>
> 100% agreed.
>
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 12 22:08:28 2003