Re: [ORO][Design Discussion] translate

["Daniel F. Savarese" <df...@savarese.org>]

In message <3C...@Sun.COM>, Michael Davey - Sun UK Support Engineer
 writes:
>Thirdly, I couldn't decide whether to implement an ORO
>tr compiler and matcher as if it were regex (which tr
>isn't), or rather to hide all the implementation in
>some private class where the code is similar to
>the internals of the tr(1M) Linux/Unix command.

Since tr deals with character sets, and only performs translations, I
think it needs to be handled slightly differently.  From the public
interface point of view, I'd suggest something like

  String translate(CharacterSet src, CharacterSet dest, String input);
  String translate(CharacterSet src, CharacterSet dest, String input,
                   int options);

Although the whole business of returning the result as a String or
storing it in a StringBuffer or other sink or taking the input as
a String depends on what the anticipated common use will be.

At any rate, my view is that character sets expressed as a String can be
expensive to convert into a suitable representation to perform a
translation and they will likely be reused; so it's probably appropriate
to store them in a separate class.  The options argument would deal with
the cds modifiers (U and C have no meaning in Java).

The translate method(s) would be the primitive functionality providing
maximum flexibility for the Java programmer.  Then a convenience method
could be added to Perl5Util or in a separate class if more appropriate
that uses the tr///cds or y///cds syntax and looks something like
  String translate(String translation, String input);
and takes care of parsing the translation expression into the proper
arguments for the primitive translate() methods, optionally keeping a
cache of translation expressions.  Whatever supporting classes that
would be necessary to implement these public interfaces could be package
local or private.

Anyway, that's my take on how to address flexibility and convenience
in addition to consistency with the existing APIs.  But it sounds like
Nicholas has already done a lot of the legwork with jtr (I haven't
looked at it yet), so maybe there are some better ideas there or it's
just a simple matter of wrapping the inner workings of jtr with a
jakarta-oro-style API.

daniel



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>