lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Mateja <>
Subject Re: Lucere project announcement
Date Thu, 11 Nov 2010 18:51:50 GMT
I think extension methods will be a great tool to supplement functionality
onto existing Lucene.Net base classes.  However, in some cases I think
partial classes will be more effective.  Using partial classes, you can
actually add additional interfaces to an existing class, something which
extensions methods won't provide (they only allow you to quack like a
duck... not actually be an IDuck).

For example, many have requested that some of the core resource classes
implement IDisposable in order to support the using () {} construct.  Using
partial classes, we can maintain the IDisposable implementation separately
from the core converted class, as long as part of the automated conversion
process marks the class as partial.

Consider the current Directory class:
public abstract class Directory

By simply making this a partial class, we'd be able to do the following:
public abstract partial class Directory

in a separate file:
public partial class Directory : IDisposable
    #region Implementation of IDisposable
    private bool disposed=false;

    public void Dispose()


    protected virtual void Dispose(bool disposeManagedResources)
        if (!this.disposed)
            if (disposeManagedResources)



Peter Mateja

On Thu, Nov 11, 2010 at 12:27 PM, Alex Thompson <>wrote:

> I think a better pattern than partial classes would be extension methods
> (like the way LINQ works with IEnumerable). That way the extensions could
> be
> in a separate assembly but appear seamless with the core class.
> I don't like the name Lucere. I think it's too close and will create
> confusion. It's so close I wonder if the ASF will have something to say
> about it.
> -----Original Message-----
> From: Prescott Nasser []
> Sent: Thursday, November 11, 2010 9:46 AM
> To:
> Subject: Re: Lucere project announcement
> There is benefit to making partial classes if we want to extend, but that
> adds complexity to the conversion and doesn't do one thing to help us get
> Lucene.Net into more native .net constructs
> I personally don't even know enough about lucene yet to know where people
> would want to extend it.
> Partial classes I think will be a good move once we have a good system in
> place to convert java to .net and show that we are keeping pace
> -----Original Message-----
> From: Peter Mateja <>
> Date: Thu, 11 Nov 2010 17:20:04
> To: <>
> Subject: Re: Lucere project announcement
> I'm a bit concerned that there's going to be a fragmentation of effort
> surrounding Lucene.Net, Lucere, and Aimee, LINQ to Lucene (
>, though this appears to be dead) causing
> more confusion than not.  I do agree that initially, Lucene.Net should
> remain a line by line port.  As much as the Java idioms pulled into
> Lucene.Net can be frustrating to work with in the context of standard .Net
> development, I think it's more important to have something that works now,
> and works exactly the same as the base Lucene.  As discussed ad nauseum in
> other forums this has several key benefits.
> That said, I do long for the elegance of recent .Net language constructs
> and
> framework features.  I've heard discussion of trying to build a .Net
> "layer"
> on top of Lucene.Net.  Having dug into the Lucene.Net code a bit, I'd have
> to say that this will not be an easy task.  I'd wager that quite a bit of
> the desired .Net-ification of Lucene.Net will result from better automated
> conversion methods, which would really hinge on the direction taken by the
> Lucene.Net project, not Lucere.
> One interesting direction to take, might be to transition some of the core
> classes in Lucene.Net into partial classes, allowing additional additional
> class tooling outside of the Lucene.Net core project.  This is perhaps a
> naive suggestion, so if anyone has already considered this route, let me
> know.
> Peter Mateja
> On Thu, Nov 11, 2010 at 3:33 AM, Troy Howard <> wrote:
> > All,
> >
> > The recent discussions on this mailing list have shown a few things to
> > be
> > true:
> >
> > - Lucene.Net is definitely still a thriving project with strong
> >leadership represented by George and DIGY
> > - The community surrounding the project is vocal, vibrant and filled
> >with ideas and motivation to help
> > - There is a strong interest in seeing Lucene.Net continue as a
> >line-by-line port of Java Lucene:
> >  - It's faster and more manageable to make releases because code can
> >be automatically converted
> >  - Retains all the excellence of the Java Lucene project
> >  - Provides end users with a wealth of existing knowledge and support
> >surrounding the Java Lucene project
> > - There is a strong interest in have a more ".Net style" port of
> >Lucene
> >  - Many users feel using the Java-idiomatic API is unwieldy
> >  - There is a desire to see the code take advantage of valuable .Net
> >framework features that do not exist in Java
> >  - Performance can be improve on the .NET runtime by refactoring
> >
> > I'm very glad to see George has picked up the ball to keep Lucene.Net
> > going and applaud his commitment to keeping the project focused on
> > it's stated goals: a line-by-line port of Java Lucene that releases in
> > sync the main project.
> >
> > I'm also glad to see that a number of people have started contributing
> > in meaningful ways to the Lucene.Net project, working through the
> > action list George posted a few days ago. I would like to
> > optimistically think that crisis is well on it's way to being averted.
> >
> > I think this is a good sign that Lucene.Net will remain a vital and
> > active project as part of the ASF.
> >
> > With that said, I'd like to announce Lucere, a new Lucene-based .NET
> > project.
> >
> > The goal of Lucere is to create a "conceptual port" of Lucene for .NET
> > as contrasted with the current "syntactic port" approach taken by
> > Lucene.Net. We will start by creating a ground-up re-write of the
> > current feature set of Java Lucene 3.0.2 that is optimized for .NET.
> > This is a non-trivial task and may cause our initial release cycle to
> > be slow. Beyond that we will be spending a certain amount of time
> > upfront to design the API and architecture. While building our initial
> > architecture and design we want to take into consideration the many
> > different ideas that our community has to offer, producing what will
> > hopefully be a full featured, flexible library that integrates well
> > into a variety of kinds of applications.
> >
> > For more information, please see the project site at:
> >
> >
> >
> > We hope that the next few weeks will represent a lively discussion
> > from members of the Lucene.Net community about the idea of a new
> > project, our goals and the design and architecture of Lucere. In order
> > to keep discussion focused for both projects, please consider joining
> > the Lucere mailing list by sending a quick email to:
> >
> > <>
> > lucere+<<>
> >
> >
> > Or, if you'd rather not use email, feel free to visit the discussion
> > forums on the project site at:
> >
> >
> >
> > Hopefully there's enough interest in both concepts such that both
> > projects may continue to move forward and thrive. We fully intend to
> > have our cake and eat it too. :)
> >
> > Thanks,
> > Troy
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message