[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-oro-user
Subject:    Re: MatchActionProcessor and character encodings
From:       "Daniel F. Savarese" <dfs () savarese ! org>
Date:       2002-06-24 17:53:45
[Download RAW message or body]


In message <E17MTjx-00010Y-00@sandbox.ontopia.net>, 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:oro-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:oro-user-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]