nly accept interfaces, the missing test
> leads to problems with Token.TOKEN_ATTRIBUTE_FACTORY
> -
>
> Key: LUCENE-2088
>
g is fixed since:
Release Fixed 6u2(b01), 5.0u12(b02) (Bug ID:2144702) , hs10(b07) (Bug
ID:2146432) , 7(b07) (Bug ID:2176843)
Let's keep it in.
> AttributeSource.addAttribute should only accept interfaces, the missing test
> leads to problems with Token.TOKEN_AT
should only accept interfaces, the missing test
> leads to problems with Token.TOKEN_ATTRIBUTE_FACTORY
> -
>
> Key: LUCENE-2088
>
problem is not only that it may have no effect, it completely
breaks the behaviour of AttributeSource when you do this. Because of that the
extra check is needed.
> AttributeSource.addAttribute should only accept interfaces, the missing test
> leads to problems with Token.TOKEN_ATTRIBUTE_F
ld only accept interfaces, the missing test
> leads to problems with Token.TOKEN_ATTRIBUTE_FACTORY
> -
>
> Key: LUCENE-2088
>
...@thetaphi.de
> -Original Message-
> From: Earwin Burrfoot (JIRA) [mailto:j...@apache.org]
> Sent: Sunday, November 22, 2009 2:35 PM
> To: java-dev@lucene.apache.org
> Subject: [jira] Commented: (LUCENE-2088) AttributeSource.addAttribute
> should only accept interfaces, the mis
bq. && Attribute.class.isAssignableFrom(attClass)
What is this for? This line
bq. public A addAttribute(Class attClass) {
ensures the same at compile time.
> AttributeSource.addAttribute should only accept interfaces, the missing test
> leads to problems with Token.TOKEN
merge to 2.9 branch.
> AttributeSource.addAttribute should only accept interfaces, the missing test
> leads to problems with Token.TOKEN_ATTRIBUTE_F
AttributeSource.addAttribute should only accept interfaces, the missing test
leads to problems with Token.TOKEN_ATTRIBUTE_FACTORY
-
Key: LUCENE-2088
ct base classes instead of an
> interfaces
>
>
> Key: LUCENE-1047
> URL: https://issues.apache.org/jira/browse/LUCENE-1047
> Project: Lucene - J
--- Erik Hatcher <[EMAIL PROTECTED]> wrote:
> I didn't mean to imply that using interfaces
> themselves were a
> potential performance issue what I meant was all
> the IoC mechanisms
> that might be tossed in as factory overhead to
> construct things
&
I didn't mean to imply that using interfaces themselves were a
potential performance issue what I meant was all the IoC mechanisms
that might be tossed in as factory overhead to construct things
indirectly.
Erik
On Mar 18, 2005, at 10:22 AM, Maik Schreiber wrote:
However
However, the primary focus of
Lucene is and always will be performance. It would be important to
demonstrate that resource utilization and performance are not adversely
affected by such changes.
I can't see why interfaces should affect performance or resource utilization
in a tangibl
Erik Hatcher wrote:
Ultimately, though, the decision to refactor the codebase to use
interfaces more pervasively lies with Doug.
Actually the decision lies not with me, but with the Lucene PMC as a
group, according to Apache's voting process:
http://www.apache.org/foundation/voting.htm
k work
properly, even though I use NO METHODS in the base class. Seems silly.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 5:31 AM
To: java-dev@lucene.apache.org
Subject: Re: Interfaces
I think, though I'm not speaking for anyone here
Ultimately, though, the decision to refactor the codebase to use
interfaces more pervasively lies with Doug.
Erik
I have seen this and several other similar requests dismissed with
similar reasoning. I, myself, once made similar requests of the abstract
classes in the analysis package. Ye
On Mar 17, 2005, at 9:15 AM, Maik Schreiber wrote:
Pragmatically, have you ever had addDocument fail? If not, then what
peace of mind are you getting from such a test?
The test I've shown is not supposed to test if addDocument() fails or
not, but to test if addDocument() is invoked at all. The t
Pragmatically,
have you ever had addDocument fail? If not, then what peace of mind are
you getting from such a test?
The test I've shown is not supposed to test if addDocument() fails or not,
but to test if addDocument() is invoked at all. The tested method was
Foo.foo(), which could be doing
ugh, the decision to refactor the codebase to use
interfaces more pervasively lies with Doug.
Erik
On Mar 17, 2005, at 2:40 AM, Konstantin Priblouda wrote:
--- Robert Engels <[EMAIL PROTECTED]> wrote:
I've been pushing for making IndexReader and
IndexWriter interfaces for a
long ti
--- Robert Engels <[EMAIL PROTECTED]> wrote:
> I've been pushing for making IndexReader and
> IndexWriter interfaces for a
> long time (and changing lucene core to use them),
> but there seems a
> reluctance to do so (although I am not sure why).
> The current fact
I've been pushing for making IndexReader and IndexWriter interfaces for a
long time (and changing lucene core to use them), but there seems a
reluctance to do so (although I am not sure why). The current factory
methods could be easily moved to a IndexReaderWriter factory class. Probably
Hi,
I know the issue of using interfaces in Lucene has been discussed a few
times before. I'd like to bring that to the table once again, though,
because I think all those discussions were missing an important point: unit
testing.
Without coding to interfaces it gets quite complicated to
22 matches
Mail list logo
