Hi Doug:
I have sent an email before stating why I'd like the Token class
be extensible. But allow me to reiterate.
It is not so much what to override, it is more what extra
information I want to encapsulate in the token.
In my case, while tokenizing a file, I want to store information
such as what is the sentence the word is in and which word index is
etc. so I can figure what to store in Lucene and what not to.
Much like the org.apache.lucene.analysis.standard.Token class, it
contains more information that is accessible in the standard Token
class. Seems like Lucene, as well, it has to do this to overcome the
fact the Token class is final. Wouldn't it be simpler to make this
class to dervie from Token? Why is it done this way?
I am not sure I am 100% agree with your statement on making API
dictating its usage. I know of a quote: "A tool is successful when it
is able to do what its creator never even dreamt of". And I think
Lucene is certainly capable of that.
Just my two cents.
Thanks
-John
On Tue, 13 Jul 2004 09:12:09 -0700, Doug Cutting <[EMAIL PROTECTED]> wrote:
> John Wang wrote:
> > On the same thought, how about the org.apache.lucene.analysis.Token
> > class. Can we make it non-final?
>
> Sure, if you make a case for why it should be non-final.
>
> What would your subclasses do? Which methods would you override?
>
> Doug
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
