In message <[EMAIL PROTECTED]>, Harald Kuhn writes:
>The question is, wether it would be possible, to overload  
>processMatches(...), adding a version with either a 3rd parameter (String) to 
>specify the encoding of the InputStreamReader like 
>
>       processMatches(InputStream input, OutputStream output, String encoding)
>
>or one that uses a Reader instead of an InputStream like i did ?

That code dates back a ways and hasn't been updated for lack of anyone
having an "itch to scratch" as they say around here.  You've got an itch,
so just post a patch to oro-dev and I'll be happy to apply it (might have
a 24 to 72 hour lag though).  I think we need to keep
  processMatches(InputStream, OutputStream);
for backward compatibility in the short term, but maybe we should deprecate
it?  If we don't want to deprecate it, then I favor adding
  processMatches(InputStream, OutputStream, String encoding);
I actually don't favor deprecating the InputStream/OutputStream method
because it's a convenience.  In either case, we should add:
  processMatches(Reader input, Writer output);
processMatches(InputStream, OutputStream) can be implemented in terms
of processMatches(InputStream, OutputStream, String) which can in turn
be implemented by calling processMatches(Reader input, Writer output);
It is actually quite silly that processMatches(Reader input, Writer output);
wasn't included from the very start considering how 
processMatches(InputStream, OutputStream) is implemented now that you
mention it.

daniel



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

Reply via email to