> Up to now I rolled my own, until I
> started using org.apache.xerces.utils.HexBin.

Ditto, the classes I've contributed are seriously trivial things, but I
think that we gain value from not having to spend any more brain power
on things like Hex, Base64 - (BTW, most people just use the sun.*
implementation of Base64, but Sun expressly warns you not  to use sun.*
classes ).  Also, it would be nice not to have to include xercesImpl.jar
to get Hex ( just about every project I'm working on has Xerces in the
classpath, I could use this - it's just the prinicple of using Xerces
for Hex encoding. )

> I agree that most of the time you're looking for a
> string (when you're dealing with XML, etc.)-- I will
> think on it a bit.  I definitely agree about the
> streaming codecs, but I also agree that the previous
> objection about things like Soundex being inherently 
> un-stream-oriented is totally valid.

I'll modify Hex to work with a stream, and provide an adapter to make it
work with a String.

> Also, I think that the 
> point about encoding and decoding both just being 
> transformations is totally valid, but I'm not sure about the 
> cleanest way to represent everything yet.  
> 
> Know what I mean? 

I agree, I just needed a RefinedSoundex, and a Hex.  I had really
short-term goals, I think it may take someone else to come up with a
cleaner OO design. 

There are two types of Codecs - #1. Stream oriented codecs, and #2.
"Token" oriented codecs

One should be able to use all codecs in either form, what matters is the
underlying implementation.  For example, I should be able to get a
Base64 representation of a String with minimal effort, behind the
scenes, Base64 is a stream oriented codec.  Alternatively, I should be
able to get a Soundex from a StringReader - behind the scenes Soundex
deals with a String token.

"Token" oriented codecs would be: Soundex, RefinedSoundex, Metaphone,
PigLatin
"Stream" oriented codecs would be: Base64, Hex, Rot13

Should "Token" oriented Encoders and Decoders implement the
org.apache.commons.lang.functor.Transformer interface? 

Am I totally misunderstanding the purpose of this package?

> One thing that I think should be done to the Hex class
> right off the bat is to make the char[] hexDigits
> static final, to stop the bleeding if someone creates
> a bunch of them instead of properly looking up a
> registered instance.

Yes, I'll do that when I've got a chance. 

--------
Tim O'Brien 
Transolutions, Inc.
W 847-574-2143
M 847-863-7045




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

Reply via email to