On Wed, Mar 3, 2010 at 11:10 AM, Grant Ingersoll wrote:
>
> On Mar 1, 2010, at 2:51 AM, Michael McCandless wrote:
>
>> Yeah in the case of DirectoryReader/MultiReader, I'd like for them to
>> be final, not for performance but for door-shutting (ie the same
>> reason we make analyzers final).
>
> D
This is actually what I mean by [intentional] door shutting -- we want
to disallow extending our analyzers because it can easily lead to
sneaky problems, and, because it's so simple to make your own analyzer
that builds up the same chain.
Mike
On Wed, Mar 3, 2010 at 11:14 AM, Robert Muir wrote:
In the analyzers case, I don't think its really door-shutting. if someone
extends an Analyzer, its likely to just result in problems from the
tokenStream/reusableTokenStream mess.
On Wed, Mar 3, 2010 at 11:10 AM, Grant Ingersoll wrote:
>
> On Mar 1, 2010, at 2:51 AM, Michael McCandless wrote:
>
>
On Mar 1, 2010, at 2:51 AM, Michael McCandless wrote:
> Yeah in the case of DirectoryReader/MultiReader, I'd like for them to
> be final, not for performance but for door-shutting (ie the same
> reason we make analyzers final).
Door shutting often is not a good thing, especially in a project lik
; non-final
> >> > methods are inlined by hotspot, if the compiler is sure that the class
> was
> >> > not extended and so on. So making a method final just for inlining is
> no
> >> > longer really needed. But with final you help hotspot more. Because of
> that,
> &g
>> > e.g. the collect methods in TFDC should be final and so on. But there is no
>> > requirement anymore. And Lucene 3.1 only runs with Java 5+, so who cares?
>> >
>> > -
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
res?
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> >
t; Sent: Sunday, February 28, 2010 7:30 PM
>> To: java-dev@lucene.apache.org
>> Subject: Re: Turning IndexReader.isDeleted implementations to final
>>
>> Sorry, I think the classes? Not sure which others should be...
>>
>> Though it always spooks me out trying to
va-dev@lucene.apache.org
Subject: Re: Turning IndexReader.isDeleted implementations to final
Reading around I think that Uwe is right. Adding final will only help hotspot,
but won't guarantee that not adding it will not result in inlining. If we're
sure that these classes really should be final,
om: Michael McCandless [mailto:luc...@mikemccandless.com]
> > Sent: Sunday, February 28, 2010 7:30 PM
> > To: java-dev@lucene.apache.org
> > Subject: Re: Turning IndexReader.isDeleted implementations to final
> >
> > Sorry, I think the classes? Not sure which others shou
://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Sunday, February 28, 2010 7:30 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Turning IndexReader.isDeleted implementations to final
>
&g
Sorry, I think the classes? Not sure which others should be...
Though it always spooks me out trying to decide if something should
really be final... these two are package private so in theory nobody
should be extending them, anyway, but if out there someone subclassed
them (mixing code into oal.
What's ok? making the classes final or just the method declaration? If
classes, besides ReadOnlySegmentReader, which other impls do you think can
be made final (I'm not in front of the code)?
On Sun, Feb 28, 2010 at 7:05 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Seems OK I thin
Seems OK I think?
Mike
On Sun, Feb 28, 2010 at 12:37 AM, Shai Erera wrote:
> Hi
>
> Do you think it's worth to make some of the isDeleted method impls final,
> like in ReadOnlySegmentReader and (maybe) DirectoryReader? I'm thinking the
> classes that are perceived as final could benefit from tha
Hi
Do you think it's worth to make some of the isDeleted method impls final,
like in ReadOnlySegmentReader and (maybe) DirectoryReader? I'm thinking the
classes that are perceived as final could benefit from that, since their
impl could be inlined. Maybe just make these classes final entirely?
Sh
15 matches
Mail list logo
