lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Alecu <and...@tachyon-labs.com>
Subject Re: Considering to contribute
Date Fri, 31 Jul 2009 14:17:04 GMT
One thing I'd like to see in a future version is the implementation of 
IDisposable on the classes that have a .Close().

I already have some helper classes in a LuceneExtender project I made, 
such as:

    public class DisposableIndexWriter : IndexWriter, IDisposable
    {
        ...constructors...

        public void Dispose()
        {
            base.Close();
        }
    }

So I can then do this:

   using (var writer = new DisposableIndexWriter(IndexDirectory, new 
PorterStemmerAnalyzer()))
   {
      ..update index..
   }

But this should be implemented in the base directly. It's a very small 
diversion from the Java code base but a sensible improvement.







George Aroush wrote:
> Hi Rune,
>
> Be very carefully with any enhancement change you make or propose, they
> won't be welcome.  The goal is to keep deltas between previous ports as
> small as possible so that subsequent ports can be managed.
>
> Do a search in the archive for a background about how a port is done.  I
> documented it.
>
> As for how you can contribute, and this is for everyone who asked, please
> grab the current code off the trunk and use it.  Check the NUnit results,
> and see what if anything fails for you, and work on them.  Check "contrib"
> and port over existing projects or new once.
>
> Regards,
>
> -- George
>
> -----Original Message-----
> From: Rune Vistnes [mailto:rune.vistnes@gmail.com] 
> Sent: Thursday, July 30, 2009 6:49 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Considering to contribute
>
> Hey guys,
>
> I haven't received any response yet, so I guess I can try to take some
> initiative and see how that goes:
>
> My first proposed change is regarding to namespace imports and fully
> qualified names. I've notived that fully qualified names are being
> used alot, and in my opinion, they clutter the code, and make the code
> harder to read. Making better use of the 'using' directive is a task
> that can be automated by the use of various tools, one of which is
> ReSharper. I've already used this tool to update the code (revision
> 799135) to remove fully qualified names and use the 'using' directive
> instead- It also removed quite a few unused namespace imports. This
> change reduced the number of code warnings given by ReSharper
> considerably, and this actually helped me spot a couple of bugs in the
> code (I'm currently located at another computer and do not remember
> the details behind the bugs, but I will bring them to attention at a
> later time).
>
> Is this patch something you would be interested in applying?
>
> PS: I have noticed that trunk has started to show signs of the 2.4.0
> conversion, which is good news. Nice work!
>
> runenur
>
> On Fri, Jul 24, 2009 at 1:07 PM, runenur<runenur@gmail.com> wrote:
>   
>> Hey,
>> I've been playing with Lucene.Net for a while, and there are some issues
>> that I have noticed. First of all, it is very clear from the API that it
>>     
> is
>   
>> a more or less direct port of Lucene, and does not really feel .NET-ish.
>> Also, I've noticed that it usually takes a while for a new Lucene release
>>     
> to
>   
>> get ported to Lucene.Net. For that reason, I am considering to offer some
>>     
> of
>   
>> my time to help keeping the code base up to date and to follow the .NET
>> design guidelines in a better manner. In that regard, I have a few
>>     
> questions
>   
>> I would love if someone could answer:
>> * Does the code following a coding convention of some kind? For example,
>> I've noticed that tabbed and spaced tabs are used intermixed, leaving me
>>     
> to
>   
>> believe that might not be the case.
>> * Do there exist a prioritized list of what should or could be done to the
>> code base?
>> * How far along is the 2.4.x port?
>> With best regards,
>> runenur
>>     
>
>
>   


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