[
https://issues.apache.org/jira/browse/LUCENE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844929#action_12844929
]
Chris Male commented on LUCENE-2310:
------------------------------------
{quote}
You should also not be able to set the TokenStream in NF.
{quote}
Yes good point.
{quote}
IMO, i would keep AbstractField and only remove Fieldable, as interfaces are
not wanted in Lucene
{quote}
Actually I would like to remove both actually. There doesn't seem much reason
to keep AbstractField, especially since its already dependent on Field.XYZ and
seems only to only store all the various properties, most of which will be
moved away to FieldType anyway.
Would a compromise be to also add an UOE to setting the TokenStream in
NumericField? It does still have the concept of a TokenStream, so it is a
Field, but a specialisation which handles the TokenStream itself.
> Reduce Fieldable, AbstractField and Field complexity
> ----------------------------------------------------
>
> Key: LUCENE-2310
> URL: https://issues.apache.org/jira/browse/LUCENE-2310
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: Index
> Reporter: Chris Male
> Attachments: LUCENE-2310-Deprecate-AbstractField.patch
>
>
> In order to move field type like functionality into its own class, we really
> need to try to tackle the hierarchy of Fieldable, AbstractField and Field.
> Currently AbstractField depends on Field, and does not provide much more
> functionality that storing fields, most of which are being moved over to
> FieldType. Therefore it seems ideal to try to deprecate AbstractField (and
> possible Fieldable), moving much of the functionality into Field and
> FieldType.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
