Honestly I think not supporting empty literals is just as big a limitation as not supporting single quotes, so IMO we'd just be trading one limitation for another. i.e. if someone were to need empty literals, the things they would have to do to use them are the same things they'd have to do to support single quotes, and I can imagine use cases for both.
On Thu, May 30, 2024 at 2:48 PM Gary D. Gregory <ggreg...@apache.org> wrote: > I'm OK with Sebb's solution [1] > > Any further thoughts here? > > Gary > [1] https://github.com/apache/commons-lang/pull/1227 > > On 2024/05/29 13:37:40 Mike Drob wrote: > > On Wed, May 29, 2024 at 8:17 AM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > > (Sorry for the top post, phone) > > > > > > A case I can imagine an empty '' occurring is when the format string > itself > > > is built programmatically for example a '%s' or using string > concatenate of > > > a variable that holds a string where that string can be empty or an > "s" to > > > mark a plural or a quote for example. > > > > > > "He said '" + bla + "' to me and I waited mm minutes!" > > > > > > Far fetched? Sure 😀 > > > > > > Gary > > > > > > On Wed, May 29, 2024, 8:43 AM sebb <seb...@gmail.com> wrote: > > > > > > > On Sun, 26 May 2024 at 23:37, sebb <seb...@gmail.com> wrote: > > > > > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas < > lmous...@gmail.com> > > > > wrote: > > > > > > > > > > > > Hello Gary, > > > > > > > > > > > > Thank you for your response. Some of the new assertions indeed > fail > > > > when interpreting the duplicate single quote as an escaped quote > instead > > > of > > > > a closing and opening quote. In particular, "y' ''years' M 'months'" > is > > > > interpreted as "4 'years 0 months" while the expected text lacks the > > > quote > > > > before "years". Same for "hello''world": it's interpreted as > > > "hello'world" > > > > instead of "helloworld". > > > > > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > > > alternate solution. > > > > > This does not cause issues with any existing tests. > > > > > > > > > > However, it does change the behaviour of a duplicate single quote > > > > > which is found outside an existing opening and closing quote. > > > > > Instead of the empty string, it generates a lone single quote. > > > > > > > > > > Whilst this is a change in behaviour, it seems to me that there > should > > > > > be no need for anyone to use a format that uses a pair of adjacent > > > > > single quotes to generate an empty string in the output, so it > seems > > > > > unlikely that this will cause any breakages. > > > > > > > > I've since realised that this argument could also apply to the > > > > existing test cases: is there really a use-case for adjacent constant > > > > strings? > > > > Why would anyone want to split a constant string in this way? > > > > > > This is similar to allowable string concatenation in Python, which static > > analysis flags as a warning and probable bug. > > > https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > > > > > > > AFAICT it just makes it harder to read the string. > > > > > > > > i.e. do the test cases represent a real-world use case? > > > > > > > > > > I understand this brings forth a breaking change in formats that > use > > > > two single quotes to close and open new literals (or even add an > empty > > > > string), but this is consistent with what java.text.SimpleDateFormat > > > > expects. And I believe that most developers would favor consistency > > > between > > > > format strings in equivalent classes. Thus, I think the cases > described > > > > above where the two single quotes terminate and begin a literal > should no > > > > longer be supported. > > > > > > > > I agree. > > > > > > > > My alternate solution avoids breaking the test cases, but the > downside > > > > is that the syntax is not in agreement with > > > > java.text.SimpleDateFormat, and is more verbose where a single-quote > > > > is to be inserted in an existing constant string (it requires 4 > single > > > > quotes, rather than 2). > > > > > > > > > > > > > > > > Should this change go forward, I expect it to be part of a major > > > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it > does > > > > contain a breaking change. > > > > > > > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > > > > > > > Best regards, > > > > > > Laertes > > > > > > > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > > > > Hello Laertes, > > > > > > > > > > > > > > Thank you for your interest in improving Apache Commons Lang > :-) > > > > > > > > > > > > > > Do you foresee any compatibility issues for existing call > sites and > > > > > > > format strings? > > > > > > > > > > > > > > For example, can you make your use cases work and still > support: > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > > > > > > > > > Or, should these cases no longer be supported? > > > > > > > > > > > > > > TY! > > > > > > > Gary > > > > > > > > > > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas < > lm...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains > useful > > > > methods > > > > > > > > to format a duration or period of milliseconds in the textual > > > > > > > > representation given by the format argument. It even allows > > > > arbitrary text > > > > > > > > to be printed between single quotes, on the condition that > any > > > > opening > > > > > > > > single quotes will eventually close with another single > quote. > > > > > > > > > > > > > > > > For example, > > > > > > > > DurationFormatUtils.formatDuration(64000L, "mm:ss") > > > > > > > > will return "01:04". > > > > > > > > > > > > > > > > While > > > > > > > > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'") > > > > > > > > will yield "34min 4sec". > > > > > > > > > > > > > > > > However, as per the JavaDoc page for this class > > > > > > > > < > > > > > > > > https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html > > > > > > > > > > > > > including > > > > > > > > a single quote is currently not supported. Other classes that > > > > format > > > > > > > > datetime such as the java.text.SimpleDateFormat do, by > putting > > > two > > > > single > > > > > > > > quotes next to each other. > > > > > > > > > > > > > > > > So something like > > > > > > > > new SimpleDateFormat("mm'' ss'sec'").format(new Date()); // > note > > > > the two > > > > > > > > single quotes after "mm" > > > > > > > > will return something like this: > > > > > > > > "42' 02sec" > > > > > > > > > > > > > > > > Instead, > > > > > > > > DurationFormatUtils.formatDuration(64000L, "mm'' ss'sec'") > > > > > > > > will return "01 04sec". > > > > > > > > > > > > > > > > I wish to implement support for single quotes in the > > > > DurationFormatUtils > > > > > > > > format the same way SimpleDateFormat does; by escaping it > with > > > two > > > > > > > > consecutive single quote characters. I have searched the > mailing > > > > list and > > > > > > > > found no similar request. I have already tested on the copy > of a > > > > source > > > > > > > > code, including adding tests, and no test throughout the > > > > commons-lang > > > > > > > > project failed. > > > > > > > > > > > > > > > > Please let me know if this is an acceptable change, and the > next > > > > steps to > > > > > > > > take should this move forward. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Laertes Moustakas > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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 > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
