lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Updated: (LUCENE-2076) Add
Date Tue, 17 Nov 2009 19:28:41 GMT


Uwe Schindler updated LUCENE-2076:

    Fix Version/s:     (was: 3.0)

I see no reason to duplicate this method, especially as Directory is a "reserved" word in
Lucene, being the superclass of FSDirectory.

I do not undertand the whole issue, why not simply call getFile() ?

> Add
> ------------------------------------------------------
>                 Key: LUCENE-2076
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Store
>    Affects Versions: 3.0
>            Reporter: George Aroush
>            Priority: Minor
>             Fix For: 3.1
>         Attachments: FSDirectory.patch
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such
that we are now depreciating improperly use of parameter type for some public APIs.  When
we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory().
 This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile().  This was necessary
because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo.  Why? 
In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()?  Because we can't
change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward
compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add  To
keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message