Re: Why is Field.java final?
-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 klawitter de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA9NvS1Xdt0HKSwgYRAg0IAKCFVclqmhjiD5yugIQenkQnRnELWgCgoaf2 rjrg92P0kWuMAj+wEXpH23Y= =z3rj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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]
Re: Why is Field.java final?
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]
Re: Why is Field.java final?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Field.java final?
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
