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

Re: [PATCH] eliminate -noproxy flag to SWIG

From: Philipp von Weitershausen <philipp_at_weitershausen.de>
Date: 2003-05-13 00:20:14 CEST

Greg Stein wrote:
>> - headers-to-modules ratio -- we'd like to see each header
>> handled by its own module, right?
> Nope. There is a definite cost to having a billion little extension modules.
> That is why a number of them are pulled into the util.i module.

What cost? Performance? Memory?

> If I had my druthers, there would be just a single extension module. As it
> is, I divided them along some probable use-case lines. (and also along the
> dividing line of "will the FS library be around, or will the module only be
> used client-side?")

Okay, but then then please don't call it "util". util sounds much like
optional, but it contains authentication stuff and pools, so it's
actually quite important to any application. I suggest moving core
things from util into a "core" extension module, if we can't have one
module per one header (which I still prefer, actually).

>>>>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.
> Let's avoid too many Python modules, please. One of the things that I really
> detest about Java is the one-class-one-file approach.

Yes, agreed. I was actually only picking up cmpilato's file name
suggestions. My idea of the bindings is this:

libsvn/ # contains the extension modules and those only

subversion/ # contains additional python classes and functions

Developers can then go straight ahead and import from libsvn and
optionally use stuff from the subversion package. Documentation for the
libsvn package can be obtained right from the C headers (or whatever
doxygen generates).

They also know what to expect in libsvn. I found out about FileDiff and
all these other things only after I browsed the source code. There was
not only no documentation for these things, I also did not expect any
extra python code in the bindings. It seemed quite like a hack.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 00:20:05 2003

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.