You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (Created) (JIRA)" <ji...@apache.org> on 2012/02/14 04:46:59 UTC
[jira] [Created] (LUCENE-3777) trapping overloaded ctors/setters in
Field/NumericField/DocValuesField
trapping overloaded ctors/setters in Field/NumericField/DocValuesField
----------------------------------------------------------------------
Key: LUCENE-3777
URL: https://issues.apache.org/jira/browse/LUCENE-3777
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
In trunk, these apis let you easily create a field, but my concern is this:
{code}
public NumericField(String name, int value)
public NumericField(String name, long value)
..
public Field(String name, int value, FieldType type)
public Field(String name, long value, FieldType type)
..
public void setValue(int value)
public void setValue(long value)
..
public DocValuesField(String name, int value, DocValues.Type docValueType)
public DocValuesField(String name, long value, DocValues.Type docValueType)
{code}
I really don't like overloaded ctors/setters where the compiler can type-promote you,
I think it makes the apis hard to use.
Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
For the ctors, I see two other options:
# factories like DocValuesField.newIntField()
# subclasses like IntField
I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-3777) trapping overloaded ctors/setters in
Field/NumericField/DocValuesField
Posted by "Uwe Schindler (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-3777:
----------------------------------
Priority: Blocker (was: Major)
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Priority: Blocker
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Michael McCandless (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207639#comment-13207639 ]
Michael McCandless commented on LUCENE-3777:
--------------------------------------------
I agree this is trappy! Especially because these are sugar APIs... which should especially not be trappy.
bq. I don't know what was the intention to change this in trunk,
This was my fault: I did this under LUCENE-3453... each of our Field impls (well, Field, NF, DVF) had their own setters to change their value... I consolidated all of these under Field's APIs, which I agree are trappy.
I think we should just break with 3.x here and change Field.setValue(T x) -> Field.setTValue(T x).
I prefer sugar classes (new IntField(7), new IntValueField(7)) instead of static factory methods (NumericField.newIntField(7), DocValuesField.newIntField(7))...
I'll take a crack at this.
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Priority: Blocker
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Robert Muir (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210293#comment-13210293 ]
Robert Muir commented on LUCENE-3777:
-------------------------------------
Thanks Mike, such patches go out of date quickly... +1 to commit and remove this part of the trap!
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
> Attachments: LUCENE-3777.patch
>
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Resolved] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-3777.
----------------------------------------
Resolution: Fixed
Fix Version/s: 4.0
I committed under the wrong issue -- see LUCENE-3077 for the commit log.
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
> Fix For: 4.0
>
> Attachments: LUCENE-3777.patch, LUCENE-3777.patch
>
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Chris Male (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207659#comment-13207659 ]
Chris Male commented on LUCENE-3777:
------------------------------------
bq. I prefer sugar classes (new IntField(7), new IntValueField(7)) instead of static factory methods (NumericField.newIntField(7), DocValuesField.newIntField(7))...
+1 to sugar classes. It gives us strong type safety and the ability to add new classes overtime.
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-3777) trapping overloaded ctors/setters in
Field/NumericField/DocValuesField
Posted by "Michael McCandless (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless updated LUCENE-3777:
---------------------------------------
Attachment: LUCENE-3777.patch
Patch, splitting NF into Int/Long/Float/DoubleField, and changing
Field.setValue(T value) -> Field.setTValue(T value).
Tests pass... I'd like to commit this first (big, rote patch, will
conflict soon) and then do DocValuesField separately...
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
> Attachments: LUCENE-3777.patch
>
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207560#comment-13207560 ]
Uwe Schindler commented on LUCENE-3777:
---------------------------------------
The biggest trap is silently creating wrong types that are incompatible with what your index has:
new NumericField(..., 5L) vs new NumericField(..., 5) is producing something totaly different. Please note the "L", forgetting to add this, you suddenly get completely incompatible fields.
This is unreleaseable!
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Michael McCandless (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210299#comment-13210299 ]
Michael McCandless commented on LUCENE-3777:
--------------------------------------------
Thanks Robert, I committed first part... I'll leave this open to work on DocValuesField next.
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
> Attachments: LUCENE-3777.patch
>
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Assigned] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Michael McCandless (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless reassigned LUCENE-3777:
------------------------------------------
Assignee: Michael McCandless
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters
in Field/NumericField/DocValuesField
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207556#comment-13207556 ]
Uwe Schindler commented on LUCENE-3777:
---------------------------------------
Hi Robert,
that type overloading was exactly the reason why in 3.x we have setXxxValue(). I don't know what was the intention to change this in trunk, but the type overloading on int/long/float/byte is very trappy. We should change this back to what we had in 3.x!
bq. factories like DocValuesField.newIntField()
Thats how NumericRangeQuery looks like (it's exactly to overcome the problem with type overloading).
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-3777) trapping overloaded ctors/setters in
Field/NumericField/DocValuesField
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless updated LUCENE-3777:
---------------------------------------
Attachment: LUCENE-3777.patch
Patch fixing DocValuesField: I broke up DocValuesField into one Field class per type (IntDocValuesField, etc.).
> trapping overloaded ctors/setters in Field/NumericField/DocValuesField
> ----------------------------------------------------------------------
>
> Key: LUCENE-3777
> URL: https://issues.apache.org/jira/browse/LUCENE-3777
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Priority: Blocker
> Attachments: LUCENE-3777.patch, LUCENE-3777.patch
>
>
> In trunk, these apis let you easily create a field, but my concern is this:
> {code}
> public NumericField(String name, int value)
> public NumericField(String name, long value)
> ..
> public Field(String name, int value, FieldType type)
> public Field(String name, long value, FieldType type)
> ..
> public void setValue(int value)
> public void setValue(long value)
> ..
> public DocValuesField(String name, int value, DocValues.Type docValueType)
> public DocValuesField(String name, long value, DocValues.Type docValueType)
> {code}
> I really don't like overloaded ctors/setters where the compiler can type-promote you,
> I think it makes the apis hard to use.
> Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
> For the ctors, I see two other options:
> # factories like DocValuesField.newIntField()
> # subclasses like IntField
> I don't have any patch for this, but I think we should discuss and fix before these apis are released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org