[
https://issues.apache.org/jira/browse/LUCENE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213519#comment-13213519
]
Simon Willnauer commented on LUCENE-3807:
-----------------------------------------
bq. This shows up in a number of places. I have mixed feelings about certain
types having a comparator and others not having it, but it's minor.
well this an indicator if we know something about the order or not. if you get
null there is not order specified...
bq. BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It
would be nicer to have a sort on disk if something doesn't support sorted
iteration order.
this is the ultimate goal... see my comment above ({noformat} next steps would
be cleaning up the in-memory sorting stuff and use the sorter which goes to
disk to do the actual sorting internally if needed {noformat})
bq. I also wonder float -> long = 4 -> 8 bytes... would this count as an
incompatible API change (because what used to work for a given amount of RAM
won't work anymore – BufferingTermFreqIteratorWrapper again)?
see above
bq. if I remember correctly Math.min/max are intrinsics, so you can afford to
be explicit
I will upload a new patch - we use this in BytesRefComp too, I think its safe
to fix
bq. This doesn't seem necessary (lookup accepts a CharSequence?).
right - leftover from an old iteration
bq. Why not a specific covariant here?
that would be Float get(String) or Float get(CharSequence) or... ;)
> Cleanup suggester API
> ---------------------
>
> Key: LUCENE-3807
> URL: https://issues.apache.org/jira/browse/LUCENE-3807
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/other
> Affects Versions: 3.6, 4.0
> Reporter: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch
>
>
> Currently the suggester api and especially TermFreqIterator don't play that
> nice with BytesRef and other paradigms we use in lucene, further the java
> iterator pattern isn't that useful when it gets to work with TermsEnum,
> BytesRef etc. We should try to clean up this api step by step moving over to
> BytesRef including the Lookup class and its interface...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
