On 2/28/07, Marvin Humphrey <[EMAIL PROTECTED]> wrote:
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."
Couldn't agree more. My motivation for doing this would be keeping the public interface as minimal and simple as possible to avoid confusion rather than to act as access control. And it allows me to keep my static method names short but this would make no difference with Lucy's coding standards so I guess it is a moot point.
> 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.
Well as long as what you are talking about doesn't get in the way of writing idiomatic bindings then it all sounds good to me. I look forward to seeing what you come up with. Cheers, Dave -- Dave Balmain http://www.davebalmain.com/
