You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by "Kevin A. Burton" <bu...@newsmonster.org> on 2004/07/11 00:50:28 UTC
Why is Field.java final?
I was going to create a new IDField class which just calls super( name,
value, false, true, false) but noticed I was prevented because
Field.java is final?
Why is this? I can't see any harm in making it non-final...
Kevin
--
Please reply using PGP.
http://peerfear.org/pubkey.asc
NewsMonster - http://www.newsmonster.org/
Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by Holger Klawitter <li...@klawitter.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 13 July 2004 18:12, Doug Cutting 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.
How about the ability to provide a writer to termText in order to exchange
a word by a synonym without having to create another object?
I favor everything which makes the Lucene API less restricitve
thus making more unexpected things possible :-)
Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists <at> klawitter <dot> de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFA9NvS1Xdt0HKSwgYRAg0IAKCFVclqmhjiD5yugIQenkQnRnELWgCgoaf2
rjrg92P0kWuMAj+wEXpH23Y=
=z3rj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by John Wang <jo...@gmail.com>.
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 <cu...@apache.org> 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: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by Doug Cutting <cu...@apache.org>.
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: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jul 13, 2004, at 12:51 AM, John Wang wrote:
> Hi:
> On the same thought, how about the org.apache.lucene.analysis.Token
> class. Can we make it non-final?
I searched for uses of the Token constructors and I'm currently of the
opinion that it is ok for Token to be made non-final. Any reasons not
to open it up some?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by John Wang <jo...@gmail.com>.
Hi:
On the same thought, how about the org.apache.lucene.analysis.Token
class. Can we make it non-final?
I sent out this question 3 different times and still got no responses...
Thanks
-John
On Mon, 12 Jul 2004 18:33:04 -0700, Kevin A. Burton
<bu...@newsmonster.org> wrote:
> Doug Cutting wrote:
>
> > Kevin A. Burton wrote:
> >
> >> I was going to create a new IDField class which just calls super(
> >> name, value, false, true, false) but noticed I was prevented because
> >> Field.java is final?
> >
> >
> > You don't need to subclass to do this, just a static method somewhere.
> >
> >> Why is this? I can't see any harm in making it non-final...
> >
> >
> > Field and Document are not designed to be extensible. They are
> > persisted in such a way that added methods are not available when the
> > field is restored. In other words, when a field is read, it always
> > constructs an instance of Field, not a subclass.
>
> Thats fine... I think thats acceptable behavior. I don't think anyone
> would assume that inner vars are restored or that the field is serialized.
>
> Not a big deal but it would be nice...
>
>
>
> --
>
> Please reply using PGP.
>
> http://peerfear.org/pubkey.asc
>
> NewsMonster - http://www.newsmonster.org/
>
> Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
> AIM/YIM - sfburtonator, Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
> IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by Doug Cutting <cu...@apache.org>.
Kevin A. Burton wrote:
> Doug Cutting wrote:
>> Field and Document are not designed to be extensible. They are
>> persisted in such a way that added methods are not available when the
>> field is restored. In other words, when a field is read, it always
>> constructs an instance of Field, not a subclass.
>
> Thats fine... I think thats acceptable behavior. I don't think anyone
> would assume that inner vars are restored or that the field is serialized.
You'd be surprised what people would assume!
The bottom line is that making this non-final would enable you to do
anything that you cannot do today, and it would permit lots of folks to
try things that won't work, get confused, and complain. Part of the job
of an API is to steer you towards best practices and away from dead
ends. If there were important functionality that would be enabled by
making this non-final then I'd be for it.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
Doug Cutting wrote:
> Kevin A. Burton wrote:
>
>> I was going to create a new IDField class which just calls super(
>> name, value, false, true, false) but noticed I was prevented because
>> Field.java is final?
>
>
> You don't need to subclass to do this, just a static method somewhere.
>
>> Why is this? I can't see any harm in making it non-final...
>
>
> Field and Document are not designed to be extensible. They are
> persisted in such a way that added methods are not available when the
> field is restored. In other words, when a field is read, it always
> constructs an instance of Field, not a subclass.
Thats fine... I think thats acceptable behavior. I don't think anyone
would assume that inner vars are restored or that the field is serialized.
Not a big deal but it would be nice...
--
Please reply using PGP.
http://peerfear.org/pubkey.asc
NewsMonster - http://www.newsmonster.org/
Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by Doug Cutting <cu...@apache.org>.
Kevin A. Burton wrote:
> I was going to create a new IDField class which just calls super( name,
> value, false, true, false) but noticed I was prevented because
> Field.java is final?
You don't need to subclass to do this, just a static method somewhere.
> Why is this? I can't see any harm in making it non-final...
Field and Document are not designed to be extensible. They are
persisted in such a way that added methods are not available when the
field is restored. In other words, when a field is read, it always
constructs an instance of Field, not a subclass.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
John Wang wrote:
>I was running into the similar problems with Lucene classes being
>final. In my case the Token class. I sent out an email but no one
>responeded :(
>
>
final is often abused... as is private.
anyway... maybe we can submit a patch :)
Kevin
--
Please reply using PGP.
http://peerfear.org/pubkey.asc
NewsMonster - http://www.newsmonster.org/
Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Why is Field.java final?
Posted by John Wang <jo...@gmail.com>.
I was running into the similar problems with Lucene classes being
final. In my case the Token class. I sent out an email but no one
responeded :(
-John
On Sat, 10 Jul 2004 15:50:28 -0700, Kevin A. Burton
<bu...@newsmonster.org> wrote:
> I was going to create a new IDField class which just calls super( name,
> value, false, true, false) but noticed I was prevented because
> Field.java is final?
>
> Why is this? I can't see any harm in making it non-final...
>
> Kevin
>
> --
>
> Please reply using PGP.
>
> http://peerfear.org/pubkey.asc
>
> NewsMonster - http://www.newsmonster.org/
>
> Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
> AIM/YIM - sfburtonator, Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
> IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org