On Mar 19, 2008, at 9:31 AM, eks dev wrote:
Grant,
"Couldn't you just mark AbstractField w/ another interface for the
methods needed for 1219"
sure it can be done this way, it is just not 100% obvious to me what
benefit would that bring compared to the current patch. Adding
another interface vs modifying only AbstractField, but the fact that
you and Hoss made the proposal increases probability that I missed
something substantial in this approach?
I haven't looked that closely at it, so...
No matter what we do for 1219, until we split Document to two
classes (searching/indexing), like Hoss preached a long time ago,
it is going to be awkward to make such changes.
Well, maybe we should put 1219 off to 3.0 and maybe we should get to
3.0 sooner rather than later, as in stop adding new features and focus
on bug fixes and deprecation. :-)
----- Original Message ----
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, 19 March, 2008 12:01:34 PM
Subject: Re: Fieldable, AbstractField, Field
On Mar 19, 2008, at 6:45 AM, eks dev wrote:
Hoss, thanks for kicking-in with your "design purist" hat on :)
about your proposal,
"The best short term approach I can think of for addressing
LUCENE-1219
in 2.4:
1) list the new methods in a new interface that extends Fieldable
(ByteArrayReuseFieldable or something)
2) add the new methods to AbstractField so that it implements
ByteArrayReuseFieldable
3) put an instanceof check for ByteArrayReuseFieldable in
DocumentsWriter.
It's not pretty, but it's backwards compatible."
For short term, It is not even necessary to add new interface, we
can, just like allready done in LUCENE-1219 add these methods to
AbstractField and check instanceof for AbstractField. Keeps "not
pretty" level a bit lower.
But, If I read Mike's proposal well, he wanted to go one step
further (preserving backwards compatibility, of course!).
Something along the lines:
1. Deprecate Fieldable
2. Fold Field and AbstractField into one class, e.g. Field
implements Fieldable
3. replace all usages of Fildable in Lucene core with Field
4. deprecate, the following methods in Document:
add(Fieldable field)
Fieldable getFieldable(String name)
Fieldable[] getFieldables(String name)
these are the only way for Fieldable to enter/leave Lucene core!
5. Add equivalents that use Field
There are other classes that extend AbstractField that don't need any
info from Field, this is why I introduced the Fieldable in the first
place and also (partially) why I have been arguing that we need to be
more along the lines of Hoss' proposal on interfaces (which sounds
strikingly familiar...)
Couldn't you just mark AbstractField w/ another interface for the
methods needed for 1219, something that extends Fieldable and adds the
new methods? That way, other Fieldables can also be extended.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___________________________________________________________
Rise to the challenge for Sport Relief with Yahoo! For Good
http://uk.promotions.yahoo.com/forgood/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
http://www.lucenebootcamp.com
Next Training: April 7, 2008 at ApacheCon Europe in Amsterdam
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
