On Feb 27, 2007, at 10:19 PM, David Balmain wrote:
On 2/28/07, Marvin Humphrey <[EMAIL PROTECTED]> wrote:
> Of course you could also have public and private include files.
Hmm, can you elaborate? I'd basically given up hope that we'd be
able to maintain tight control over symbol export, and was expecting
to define the API via documentation only.
I haven't tried this before and I'm not sure if other large C projects
do this but I was thinking you could have two sets of include files;
one that contains the public API and the other used to contain methods
used internally within Lucy. For example, an IndexWriter.h and an
IndexWriter_private.h.
One way I am planning on cutting down on public methods is by keeping
the unit tests in the same file as the source code, surrounding them
with an #ifdef UNIT_TESTS. A lot of the methods in Ferret would be
static except that I needed to make them available for unit testing.
I guess I just don't care a whole lot. Words to live by, courtesy of
Larry Wall: "Perl doesn't have an infatuation with enforced privacy.
It would prefer that you stayed out of its living room because you
weren't invited, not because it has a shotgun."
If it's easy to keep separate header files, cool -- but the way I
have KS and boilerplater set up right now, it wouldn't be, and I
don't think we should make any sacrifices in clarity or simplicity
for the sake of enforcing access control. If people want to hack,
they'll hack, and you can't stop 'em. Look at what all the people on
java-dev do. :)
I agree to a certain extent. However, when I released the first
version of Ferret, a lot of people complained the interface was too
Java-like. It can be difficult to find the happy medium between making
the interface easy for people who used Lucy in a different language
and people who their Ruby/Perl/PHP library to work in a certain way.
Absolutely. What I'm suggesting wouldn't stand in the way of that.
It would even lend superficial similarity to bindings which are
otherwise implemented very differently.
But if you wanted to take this route (making it possible for binding
authors to generate some/most of the binding from some XML files), how
about using SWIG?
For Perl, at least, XS is much more powerful, albeit complex. But
regardless, I wouldn't want to elevate consistency across bindings
over idiomatic implementation.
For instance, KS uses labeled params rather than ordered args for a
lot of things. Auto-generated bindings mirroring the C interface
wouldn't let you do this:
my $filter = KinoSearch::Search::RangeFilter->new(
field => 'product_number',
lower_term => '003',
upper_term => '060',
include_lower => 1,
include_upper => 1,
);
I assume you'll want to do something similar for Ruby. If we ever
prepare Java bindings, that won't fly. But the same method
description text could -- and should -- be used in the docs for each
of them.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
