On 20 February 2017 at 14:55, Rob Tompkins <chtom...@apache.org> wrote:
>
>> 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.
I don't think it's possible to work out the number of times a string
has been escaped.
The most one can do is to determine if a string has not been escaped.
That would be the case where a string has one or more unescaped
characters in it.
For example "This & that" has obviously not been escaped.
However if a string has no un-escaped characters it it, that does not
necessarily mean that it has already been escaped.
For example: "This & that".
This might have been escaped - or it might not.
For example it could be the answer to: "How does one code 'This &
that' in HTML?"
The application has to keep track of the escape-state of the string.
> 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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
