It doesn't subclass Field b/c I didn't want to deal with the
constructors (Field does not have an empty constructor) and everything
and I didn't think LazyField should be exposed publicly at the API
level. It is not something you want people instantiating ever b/c then
they will try to add them to a Document on indexing and I don't think
that is appropriate. To me, all I wanted to make sure of is that the
thing coming out of FieldsReader contained a valid field (lower case f
intentional), hence the new interface.
Also, I think if you look back in the archives, there was a lot of
discussion on how to do this, so that may help inform this discussion
(search for subject "Lazy Field Loading")
As for getField versus getFieldable, I think getField should be
deprecated and a note put on it not to use it if you are using the new
FieldSelector mechanism otherwise a class cast exception will occur.
-Grant
Chris Hostetter wrote:
: I was assuming it would be changed so that LazyField extended Field.
in which case we wouldn't really need a LazyDocument class .. Document
could be used (and could contain LazyField's directly)
I don't know why LazyField doesn't subclass Field ... but i assume there's
a good reason (becuaes it looks like a lot of work went in to extracting a
bunch of logic into a new abstract super class)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
School of Information Studies
335 Hinds Hall
Syracuse, NY 13244
http://www.cnlp.org
Voice: 315-443-5484
Fax: 315-443-6886
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
