Robert, Thanks for stepping in,
I personally found some of your suggestions quite interesting and completely agree that Lucene 3.0 may help quite a bit. Not that I want to place myself in the bullseye of any .NET snipers out there but the .NET framework (like any others) has its share of quirks. The main one that comes to mind is the garbage collector which is different than in Java. The same can be said for some of the behavior of the CLR when compared to the JVM. I recall implementing IDisposable myself in a few objects and while you may consider that the GC should run and free resources by calling Dispose on an IDisposable object this is actually a technique that is discouraged because there is no telling when the GC will actually free up a resource - you may laugh at this but when it comes to bad practices I've seen newbie .NET programmers easily create memory leaks by not manually closing resources (in a world where a GC exist, who would have thought...) In the end, the languages are different - the whole conversation about Generics could also be a very interesting topic, we could also talk about WCF quite a bit. This is where personally the line-to-line port of Lucene from Java to .NET is IMHO a difficult endeavor. One would not try to do a line-to-line port from Java to Perl. The languages are too different. But I think that because people perceive similarities between C# and Java that it is assumed that it's a good idea. However - and this is where opinions diverge - this would be in my point of view like trying to fit a gas engine in a diesel car. While the purposes are the same, the implementations should be different (at least in some areas) because the technologies are different. My Canadian 2 cents - subject to the exchange rate Karell Ste-Marie C.I.O. - BrainBank Inc -----Original Message----- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Tuesday, January 04, 2011 11:27 AM To: lucene-net-dev@lucene.apache.org Subject: Re: Proposal Stage: Net Idiomatic Api Version On Tue, Jan 4, 2011 at 10:49 AM, Peter Mateja <peter.mat...@gmail.com> wrote: >> I made a request of the community in the Lucere project mailing list >> to respond with ideas about what an ideal .NET API would look like, >> and how it would function. Specifically, I was hoping to get >> pseudo-code examples of how end users would like to use Lucene. Even >> something as simple as: >> >> using(var luceneIndex = new LuceneIndex.Open("C:\foo\bar")) { >> var hitDocs = from doc in luceneIndex where >> doc.Field["content"].Match("foo") select doc; } Hi guys, I know almost nothing of .NET (lucene java developer here), but I was hoping I could provide some suggestions here to help out. In glancing at some of the issues surrounding a more ".NET" api, i couldn't help but notice many of the issues people complain about, are because lucene.net hasn't implemented lucene 3.0 # lucene 3.0.x is the same feature-wise as lucene 2.9.x, no new features. # lucene 3.0.x is Java 5, which is almost a different programming language than Java 4 (2.9.x). This means enums, generics, Closeable, foreach (instead of Iterators), autoboxing, annotations, etc. A lot of the issues people have raised seem to be due to the fact that lucene 2.9.x is in an ancient java version... I think if you ported 3.0, things would look a lot more idiomatic (although surely not perfect for .NET users, but better!). For example, taking a glance, I people making the .NET forks actually doing things like taking the 2.9.x code and converting Field.java to use enums, which is really a duplication of effort since we did this in java over a year ago!: http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/src/java/org/apache/lucene/document/Field.java So, I'm suggesting that one thing you could consider is to start focusing on lucene 3.0.x, to also produce a more idiomatic api automatically, and possibly this would be a good enough improvement to bring in some developers from those forks. Separately, I'm trying to understand the syntax you provided about IDisposable/using. Obviously, as part of your porting process you could take anything marked Closeable [we marked anything wtih a .close() as Closeable in Lucene 3.0], and mark it IDisposable, but is this really the best approach? For example, the syntax you provided seems like it would encourage closing the IndexReader and opening a new one for each search request... yet this is about the biggest no-no you can do with a lucene index... opening a new IndexReader is very heavy and you should re-use it across queries and not open/close them often... so in this case, a more idiomatic API could actually be bad, if it encourages worst practices...
