Robert... good points all. I especially agree that basing initial idiomatic work on 3.0+ makes sense (indeed, I believe this is what Lucere.Net had agreed to do.)
Use of IDisposable can certainly lead to worst practices concerning IndexReader / IndexWriter objects. However, the IDisposable pattern (if implemented correctly... see http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx, http://www.codeproject.com/KB/dotnet/idisposable.aspx and Framework Design Patterns book mentioned earlier), really is the best way (in .Net) to ensure proper handling of both unmanaged resources, and stateful managed resources. I think a good combination of documentation and examples could do much to discourage worst practices. In some cases, the sample 'using' code you refer to might be appropriate... though in most the lifetime of an IndexWriter object might be controlled at a higher context (AppDomain, etc.) Let's ensure that Lucene.Net users know the how and why for each approach. Peter Mateja peter.mat...@gmail.com On Tue, Jan 4, 2011 at 10:41 AM, Karell Ste-Marie <stema...@brain-bank.com>wrote: > 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-...@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... >
