lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Sale <dougs...@gmail.com>
Subject Re: Considering to contribute
Date Fri, 31 Jul 2009 16:32:30 GMT
This sounds like a good idea to me.  Please create a JIRA entry for this.

On Fri, Jul 31, 2009 at 9:17 AM, Andrei Alecu<andrei@tachyon-labs.com> wrote:
> 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
View raw message