But segmentFileName performs the concatenation internally:
static String segmentFileName(String segmentName, String ext) {
return segmentName + "." + ext;
}
So that would not avoid anything right?
And still, if someone needs to know whether a certain file is a core Lucene
file or his own added file, he'll need to add the ".". I guess I don't
understand why not to define the constants with the ".'? Although I didn't
do a through scan through the code, I didn't find in places I checked that a
reference to *just* the extension name is needed.
And thanks for correcting me on the package-private and back-compat thing.
In my mind it was already public :).
Shai
On Tue, Feb 23, 2010 at 1:16 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> This class makes me somewhat nervous, with the changes coming in flex,
> because the extensions are no longer static but rather a function of
> the particular codec you're using in the index. I've changed some of
> the constants accordingly (on flex).
>
> Still, I think it's OK to make it public (flex has in fact done so,
> since codecs, in different packages, need to reference the constants),
> but mark it as @lucene.internal.
>
> There is no back compat issue here -- it's package private currently.
> Even once it's public with @lucene.internal, there's still no back
> compat since it's internal.
>
> I would love to never do our own concatenation in Lucene's sources,
> and instead consistently use IndexFileNames.segmentFileName method
> whenever we need to build up a file. Then it's OK that the extensions
> do not include the '.'?
>
> Mike
>
> On Tue, Feb 23, 2010 at 1:42 AM, Shai Erera <ser...@gmail.com> wrote:
> > Hi,
> >
> > I've noticed that IFN is package private, including its constants and
> > methods. Any reason why not make it public? I need to create my own
> > Directory, and would like to query whether a file is 'my file' or
> Lucene's
> > file. Getting access to the extensions can help. Currently I have to put
> my
> > code in o.a.l package, which I prefer not to.
> >
> > Also, I think the constants could be wrong in some situations. They only
> > include the extension itself, w/o the "." part. That leads to many places
> in
> > the code where I see this <code>fname + "." + IFN.extension</code>. Two
> > problems:
> > (1) Doing "." + ext is just a waste - it's really not needed.
> > (2) If someone only checks for the extension, without adding the "."
> part,
> > he can accidentally think that fnamedel is a deletion file ..
> >
> > I'd like to patch this, but want to validate with the community before I
> > create an issue. Making it public is trivial. Changing the extension name
> is
> > more problematic for back-compat, but I think currently it's just wrong
> ...
> > Unless we come up w/ new names for the extensions, which is annoying. Can
> we
> > sacrifice back-compat for this thing?
> >
> > Thanks,
> > Shai
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
