On Mar 13, 2008, at 5:35 AM, Michael McCandless (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578199
#action_12578199 ]
Michael McCandless commented on LUCENE-1219:
--------------------------------------------
Alas, I'm not really happy with introducing this API at the
AbstractField level and not in Fieldable. It's awkward that we've
deprecated binaryValue() in AbstractField and not in Fieldable. But,
I think it's our only way forward with this issue without breaking
backwards compatibility.
In 3.0 I'd like to at least promote this API up into Fieldable, but
even that is somewhat messy because I think in 3.0 we would then
deprecate binaryValue() and move these 3 new methods up from
AbstractField.
What I'd really like to do in 3.0 is change Fieldable to not be an
abstract base class instead.
Question: could we simply move forward without Fieldable? Ie,
deprecate Fieldable right now and state that the migration path is
"you should subclass from AbstractField"? I would leave "implements
Fieldable" in AbstractField now, but remove it in 3.0. As far as I
can tell, all uses of Fieldable in Lucene are also using
AbstractField.
I guess I don't really understand the need for Fieldable. In fact I
also don't really understand why we even needed to add AbstractField.
Why couldn't FieldForMerge and LazyField subclass Field? It's
somewhat awkward now because we have newly added APIs to Field, like
setValue(*), which probably should have been added to Fieldable.
Here's the relevant threads:
http://lucene.markmail.org/message/e7tczz6262yg2bpm?q=Fieldable+list:org%2Eapache%2Elucene%2Ejava-dev+from:%22Grant+Ingersoll%22&page=2
and
http://lucene.markmail.org/message/sdqntkhzfy2su7fk?q=Fieldable+list:org%2Eapache%2Elucene%2Ejava-dev+from:%22Grant+Ingersoll%22
Also: LUCENE-545
I think at the time, the reason I didn't subclass from Field was
because there are values on Field that just don't make sense in the
context of a LazyField, namely the constructors don't make sense, nor
do all of the options for what a Field is as produced during Indexing,
versus a Field at retrieval.
This gets to Hoss' point, is that the whole overloading of Document/
Field for both indexing and search doesn't make sense, but that is a
discussion for the mailing list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
