lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Knize <nkn...@gmail.com>
Subject Re: [Possibly spoofed] Re: Solr/Lucene 6.x: Multiple public Query classes not immutable (yet)
Date Thu, 03 Mar 2016 19:04:21 GMT
Hi Luc, I'm OK with you backporting this to 6.0. I think its important for
shoring up the API.

On Thu, Mar 3, 2016 at 8:24 AM, Adrien Grand <jpountz@gmail.com> wrote:

>
>
> Le jeu. 3 mars 2016 à 15:13, Vanlerberghe, Luc <
> Luc.Vanlerberghe@bvdinfo.com> a écrit :
>
>> -          I didn’t leave any public MultiPhraseQuery constructors like
>> you did for PhraseQuery.  Adding a few afterwards shouldn’t break anything
>> though.
>>
>
> I think it's good this way: I added them for PhraseQuer because I thought
> it should be easy to create simple phrase queries but maybe it was a
> mistake. MultiPhraseQuery on the other hand is an expert query so I'm
> totally fine with not having convenience constructors.
>
>
>> -          The private termArrays and positions members could become
>> fixed arrays like you did for PhraseQuery.  This would change the signature
>> of getTermArrays() and getPositions(), so perhaps it should happen now…
>>
> Actually I think returning a list is better: with arrays you need to
> perform a deep copy if you want to make sure that the user cannot change
> the internal state of the query. We could keep arrays internally and call
> Collections.unmodifiableList(Arrays.asList(termArrays)) when returning the
> terms to the user?
>
>

Mime
View raw message