: > Having Document implement Map sounds reasonable to me though. Any
: > reasons not to do this?
:
: Not really, except perhaps that a Lucene Document could theoretically
: have multiple identical keys... not something that anyone would want to
Assuming you want all changes to be backwards compatible, you pretty much
have to impliment Map.get(Object):Object usig Document.get(String):String
... otherwise you'll wind up really confusing the hell out of people. But
If you really wanted to be mean to people, I guess you could use
Document.getField(String):Field or even
Document.getValues(String):String[] or Document.getFields(String):Fields[]
if you were feeling particularly mean.
The real question in my mind is not "how should we impliment 'get' given
that we allow multiple values?", a better question is "how should we
impliment 'put'?"
do you write...
Object put(Object k, Object v) {
this.add((Field)v);
return null;
}
or...
Object put(String k, String v) {
this.add(Field.Text(k.toString(),v.toString()));
return null;
}
or...
Object put(String k, String v) {
throw new UnsupportedOperationException("we're not that nice");
}
...i think it may be wiser to just let clinets wrap the Doc in their own
Map, using the rules that make sense to them -- becuase no ones ever going
to agree 100%.
If you think you know how to satisfy 90% of the users, i would still
suggest that instead of making Codument impliment Map, instead add
a "toMap()" functin that returns a wrapper with the rules that you think
make sense. (and leave the Document API uncluttered of the Map functions
that people who don't care about Map don't need to see)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
