There have been many major successful libraries where the interfaces
change from one (major) version to the next.
Programmers are used to it, and quite apt at dealing with it.
But, in the cited case, it is a perfect example where Field being an
interface and DefaultField being a default impl
[
https://issues.apache.org/jira/browse/LUCENE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiroaki Kawai updated LUCENE-1241:
--
Attachment: ComparableCharSequence.java
ComparableCharSequence illustrates the idea. I wanted
[
https://issues.apache.org/jira/browse/LUCENE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581768#action_12581768
]
Hiroaki Kawai commented on LUCENE-1241:
---
I think we should not use \u as a termi
Get rid of (another) hard coded path
Key: LUCENE-1244
URL: https://issues.apache.org/jira/browse/LUCENE-1244
Project: Lucene - Java
Issue Type: Improvement
Components: Analysis
Repor
[
https://issues.apache.org/jira/browse/LUCENE-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hasan Diwan updated LUCENE-1244:
Attachment: lucene.pat
> Get rid of (another) hard coded path
> --
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581758#action_12581758
]
Yonik Seeley commented on LUCENE-831:
-
> I agree that it would be nice to skip the Stri
Yeah, I tend to think Open Source development should favor abstract
classes, since there is no way of knowing all the different things so
many varied users will come up with over time. I suppose one could
argue for more "major" upgrades to offset that, or more relaxed rules
about interface
Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov) agrees with a dissenter
(Alexander Jung, a.k.a. "AJ.NET"), who re-states the rule of thumb as:
"An interface should define at most one contract."
But what if you want to expand the contract? For example, Field
On 03/24/2008 at 5:32 PM, Doug Cutting wrote:
> Chris Hostetter wrote:
> > in my opinion other blog he links to hits the nail on the head a
> > little better (i remember reading this last year) ...
> >
> http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
>
> The r
I have to agree with the blog (it terms of interfaces/classes and
'why Lucene isn't all that). Of course, it seems like we have faced
almost the exact same problems.
If you read farther down in the comments there is a very specific
example that explains the problem quite well.
There is al
Chris Hostetter wrote:
in my opinion other blog he links to hits the nail on the head a
little better (i remember reading this last year) ...
http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
The rule of thumb there is good too:
"An interface should define a
: i enjoy reading Carp's blog, he has/had the same dilemma :) interfaces
: vs abstract classes, nice reading on http://lingpipe-blog.com/
FYI: direct link...
http://lingpipe-blog.com/2008/03/19/abstract-base-classes-vs-interfaces/
in my opinion other blog he links to hits the nail on the head
: IndexReader would not instantiate a subclass in this example. I was just
: saying your wrapping example doesn't require an interface: it works equally
: well if ReadOnlyDocument is a concrete class. I think moving away from
: interfaces for 3.0 makes sense.
i don't know that it works equally
[
https://issues.apache.org/jira/browse/LUCENE-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581662#action_12581662
]
Doug Cutting commented on LUCENE-1231:
--
How would this compare to making the storing
[
https://issues.apache.org/jira/browse/LUCENE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1242.
Resolution: Fixed
> small speedups to bulk merging
> -
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/414/changes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Spookily, I believe this is in fact some sort of JVM hotspot compiler
bug. Adding -Xbatch (forces up-front compilation) prevents (works
around) the problem.
I added a counter, to IndexOutput, of total bytes written, and then
in SegmentMerger.mergeFields, I added an assert that the #docs
17 matches
Mail list logo
