> On Feb 20, 2017, at 4:31 AM, sebb <seb...@gmail.com> wrote:
>
> On 19 February 2017 at 14:29, Raymond DeCampo <r...@decampo.org
> <mailto:r...@decampo.org>> wrote:
>> 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("&amp;"). That means the proposed escape() method would also
>> have the same output for "&" and "&amp;".
>>
>> I think a better approach for an idempotent escape would be to just
>> unescape the string once, and then run the traditional escape.
>
> That does not eliminate the problems, as you state below.
>
>> 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.
>
> That is my exact point.
>
> Since it's not possible for the function to work reliably, we should
> not mislead users by pretending that there is a magic method that
> works.
>
>> 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.
>
> +1
I’m a (+1) for removal as well.
Also, I didn’t mean for my example to sound like a proposal. I merely was
trying to get to a potentially valuable stateless idempotent string escape
function. Its contrivance it quite clear.
Any other comments out there?
We could provide a stateful escaper (that figures out how many escapes a string
is in), or a method that returns the number of escapes in a string is. Again,
I’m not all that sure on the value of such methods.
Cheers,
-Rob
>
>>
>> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
> <mailto:dev-h...@commons.apache.org>
