[
https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779101#action_12779101
]
George Aroush commented on LUCENE-2076:
---------------------------------------
Mark's response is right on. I'm also fine with adding getDir(), but prefer to
see getDirectory().
Uwe, the issue (and I just realized, I didn't clarify this in my original
description of this issue) is with the way Java treats java.io.File objects,
which can be a file or a directory. As I pointed in the description of this
issue, for .NET, a file is managed using System.IO.FileInfo, and a directory is
managed using System.IO.DirectoryInfo. Up to Lucene.Net 2.4.0, all ports were
done such that we are using System.IO.FileInfo. This meant, internally, and
even for public API's, we have to first make sure the object is a directory
before using it.
With 2.9.1, anywhere we were using System.IO.FileInfo, we are now depreciating
them in favor of using System.IO.DirectoryInfo. The one area where we could
not do this is for org.apache.lucene.store.FSDirectory.getFile() this is
because the issue is with the return type -- thus, we can't overload the method
name.
This is why, in Lucene.Net, we added
Lucene.Net.Store.FSDirectory.GetDirectory() and flaged
Lucene.Net.Store.FSDirectory.GetFile() as depreciated. To keep the APIs
consistent between Java and Lucene.Net, I'm requesting that Java Lucene add
org.apache.lucene.store.FSDirectory.getDirectory().
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> 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
> org.apache.lucene.store.FSDirectory.getDirectory()? 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
