Idisposable has more to do releasing resources and gc
On Tue, Jan 4, 2011 at 11:27 AM, Robert Muir <rcm...@gmail.com> wrote:
> 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...
>
--
Michael Herndon
Senior Developer (mhern...@o19s.com)
804.767.0083
[connect online]
http://www.opensourceconnections.com
http://www.amptools.net
http://www.linkedin.com/pub/michael-herndon/4/893/23
http://www.facebook.com/amptools.net
http://www.twitter.com/amptools-net
