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]
