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
libsvn/_client.so
libsvn/_wc.so
libsvn/client.py
libsvn/wc.py
...
subversion/ # contains additional python classes and functions
subversion/client.py
subversion/wc.py
...
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.
Phil
---------------------------------------------------------------------
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