: IndexReader would not instantiate a subclass in this example. I was just : saying your wrapping example doesn't require an interface: it works equally : well if ReadOnlyDocument is a concrete class. I think moving away from : interfaces for 3.0 makes sense.
i don't know that it works equally well. but i agree it can work. "moving away from interfaces" is more of a concrete statement then i'd like to make ... moving away from big interfaces yes, but i think there are probably situation in the Lucene code base where more simple "...able" type interfaces (in the vein of Callable, Runnable, etc...) could make sense. : Agreed, it's a dangerous trap to make this look simple. EG, I just discovered : that if you call "isIndexed()" on a Fieldable in the document returned by an : IndexReader, it can lie, because it falls back to FieldInfos to check that : field. But this is not right since on adding the one doc you could have : specified NOT to index that one field and only store it. Also, getBoost() : doesn't survive indexing. In short, it's buggy, today, that we try to act : like a retrieved document has faithfully preserved these detailed index-time : settings. bingo ... just because things have the same name, doesn't mean they should *be* the same implementation from a common base class. : So the IndexableDocument abstract base class would only define getters. well, also some protected variables backing up those getters, either that or make all of them abstract ... but yeah. : StoredDocument abstract base class would only define getters. There would be : a (package-)private class in oal.search that subclasses this and adds private : setters. Likewise for Field, or, maybe StoredDocument deals directly in : String and doesn't make Field classes (Yonik's idea). i would certain vote for StoredDocument implementing Map<String,Iterable<String>> : I've flipped here and would be happy not to expose any of this API in the : returned document. ...the key being that if we do return those types of things aas part of the "document" they should be via methods which are not the same as the methods used when indexing ... perhaps they should even be part of a "DocumentMetadata" object which you have to explicitly ask for either when fetching the document or later via docId (so people that just want fast access to to the stored fields can save some cycles) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
