Suggestion for Token.java

2004-04-13 Thread Holger Klawitter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

Just a short suggestion:

It would be useful to make Token.termText public (or to provide a reader/
writer pair).

That way one can create TokenFilters altering termText (for Synonyms for 
example) in other packages as org.apache.lucene.analyzer.

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists at klawitter dot de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAe/C41Xdt0HKSwgYRAoUEAKCUARoxSFiPv6OyJCzJhbLCLbtkmwCfQHzH
pH4Z4Bk6M/emmLn0CVoEX8w=
=1fIA
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Suggestion for Token.java

2004-04-13 Thread Erik Hatcher
What is wrong with simply creating a new token that replaces an 
incoming one for synonyms?

I'm just playing devil's advocate here since you can already get 
the termText() through the public _method_.

	Erik

On Apr 13, 2004, at 9:52 AM, Holger Klawitter wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,

Just a short suggestion:

It would be useful to make Token.termText public (or to provide a 
reader/
writer pair).

That way one can create TokenFilters altering termText (for Synonyms 
for
example) in other packages as org.apache.lucene.analyzer.

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists at klawitter dot de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFAe/C41Xdt0HKSwgYRAoUEAKCUARoxSFiPv6OyJCzJhbLCLbtkmwCfQHzH
pH4Z4Bk6M/emmLn0CVoEX8w=
=1fIA
-END PGP SIGNATURE-
-
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: Suggestion for Token.java

2004-04-13 Thread Holger Klawitter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Erik,

 What is wrong with simply creating a new token that replaces an
 incoming one for synonyms?
 I'm just playing devil's advocate here since you can already get
 the termText() through the public _method_.

Well, you're right; I forgot about cloning, but ... (Lords advocate :-)

1.) Cloning implies the need to change filters whenever the fields in Token 
change.

2.) In presence of so many finals it's quite consistent to avoid creation of 
objects in favour of reuse.

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists at klawitter dot de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAfFxL1Xdt0HKSwgYRAkSRAJoDQcdpeGEl6PaqkqLqYSuzOq+DMQCgoUh9
3jbhzhz00QvH4EUiJgVFgus=
=2FEm
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Suggestion for Token.java

2004-04-13 Thread Tatu Saloranta
On Tuesday 13 April 2004 15:31, Holger Klawitter wrote:
 Hi Erik,

  What is wrong with simply creating a new token that replaces an
  incoming one for synonyms?
  I'm just playing devil's advocate here since you can already get
  the termText() through the public _method_.

 Well, you're right; I forgot about cloning, but ... (Lords advocate :-)

 1.) Cloning implies the need to change filters whenever the fields in Token
 change.

On the other hand, one needs to be sure that no other code assumes Tokens are 
immutable. For example, if they weren't one couldn't reliably use tokens in 
Sets or Maps (not sure if it's useful to do that, just an example).

I guess it's really matter of whether tokens were designed as immutable (which 
often makes sense for similar objects), or if they just happen to be, due to 
lack of modifier method(s).

-+ Tatu +-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]