[
https://issues.apache.org/jira/browse/LUCENE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010036#comment-13010036
]
Chris Male commented on LUCENE-2310:
------------------------------------
bq. So, what is the reason for doing this in 3.x at all, can't we simply drop
stuff in 4.0 and let 3.x alone?
Very good question. Certainly we are simplifying the codebase and I feel that
Field is what most users use (not AbstractField). But I know some expert users
do use AbstractField. But maybe they can handle the hard change?
> 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-CleanField.patch,
> LUCENE-2310-Deprecate-AbstractField.patch,
> LUCENE-2310-Deprecate-AbstractField.patch,
> LUCENE-2310-Deprecate-AbstractField.patch,
> LUCENE-2310-Deprecate-DocumentGetFields-core.patch,
> LUCENE-2310-Deprecate-DocumentGetFields.patch,
> LUCENE-2310-Deprecate-DocumentGetFields.patch, LUCENE-2310.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
