commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@apache.org>
Subject Re: [text] On the value of idempotent string escape methods?
Date Mon, 20 Feb 2017 14:55:20 GMT

> On Feb 20, 2017, at 4:31 AM, sebb <sebbaz@gmail.com> wrote:
> 
> On 19 February 2017 at 14:29, Raymond DeCampo <ray@decampo.org <mailto:ray@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("&amp;") would evaluate to "&".  So would
>> unescape("&amp;amp;").  That means the proposed escape() method would also
>> have the same output for "&amp;" and "&amp;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 "&amp;" 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 <chtompki@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message