I am trying to see how having the proposed unescape() method leads to an a
useful escape method.
E.g. clearly unescape("&") would evaluate to "&". So would
unescape("&"). That means the proposed escape() method would also
have the same output for "&" and "&".
I think a better approach for an idempotent escape would be to just
unescape the string once, and then run the traditional escape. You will
still have issues if the user intended to escape the string "&" but you
are never going to crack that without some kind of state saving.
Than given that the functionality is available via to consecutive calls to
existing methods, I would probably be disinclined to include it in the
library.
On Sat, Feb 18, 2017 at 12:04 PM, Rob Tompkins <chtom...@gmail.com> wrote:
> In preparation for the 1.0 release, I think we should address Sebb's
> concern in TEXT-40 about the attempt to create "idempotent" string escape
> methods. By idempotent I mean someMethod("some string") =
> someMethod(someMethod(someMethod(...someMethod("some string")))), a
> single application of a method is equal to any number of the applications
> of the method on the same input.
>
> Below I lay out a mechanism by which it is possible to write such methods,
> but I don’t know the value in writing such methods. I'm merely expressing
> that idempotency is a possibility.
>
> For string "un-escaping", I believe that we can write a method that,
> indeed, is idempotent by simply running the un-escape method the finite
> number of un-escapings to get to the point at which the string remains
> unchanged between applications of the un-escaping method. (I believe that I
> can write a proof that all un-escape methods have such a point, if that is
> needed for the sake of discussion).
>
> If indeed we can create an idempotent un-escape method, then we can simply
> take that method run it, and then run the escaping method one time. If we
> always completely unescape and then escape once then we do have an
> idempotent method.
>
> Such a method might not be all that valuable to the user though.
> Furthermore, this just explains one way to create such an idempotent
> method. Whether or not more or more valuable methods exists, would take
> some more though.
>
> Anyone have any thoughts? My feeling is that it might be more effort than
> it's worth to ensure that any string is only "singly encoded.” Further, we
> probably should give a look at the “escape_once” methods in
> StringEsapeUtils.
>
> Cheers
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
