Re: [lang] Considering a new String utility class
Looking through StringUtils[1]m most of the methods have an "IgnoreCase"
variant, so I don't think one needs to DO anything to achieve this. If you
want to fold the ignoreCase variants, add something like:
private static boolean disregardCase = false;
/**
* Sets case-insensitivity in a fluent manner
*/
private static StringUtils foldCase(String value) {
if(startsWith(str, prefix, false);disregardCase) {
this.value = this.value.toLowerCase();
}
}
public static StringUtils withCaseInsensitivity() {
disregardCase = true;
return this;
}
public static StringUtils withCaseSensitivity() {
disregardCase = false;
return this;
}
and change all the relevant methods to call foldCase before doing their
thing. -- H
--
OpenPGP: https://hasan.d8u.us/openpgp.asc
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
*.
Sent
from my mobile device
Envoye de mon portable
Re: [lang] Considering a new String utility class
On Thu, Mar 16, 2023, 3:15 AM Hasan Diwan wrote:
> Looking through StringUtils[1]m most of the methods have an "IgnoreCase"
> variant, so I don't think one needs to DO anything to achieve this. If you
> want to fold the ignoreCase variants, add something like:
>
> private static boolean disregardCase = false;
> /**
> * Sets case-insensitivity in a fluent manner
> */
> private static StringUtils foldCase(String value) {
> if(startsWith(str, prefix, false);disregardCase) {
>this.value = this.value.toLowerCase();
> }
> }
>
> public static StringUtils withCaseInsensitivity() {
> disregardCase = true;
> return this;
> }
>
> public static StringUtils withCaseSensitivity() {
> disregardCase = false;
> return this;
> }
>
> and change all the relevant methods to call foldCase before doing their
> thing. -- H
>
My concern is the whole idiom. Is it more natural to say
"withCaseInsensitivity" or "withoutCaseSensitivity"? From questions like
that you get to withCaseSensitivity(boolean) and from there I evolved to an
enum because its constants are more expressive than true/false. Concerns
other than case sensitivity may be non-binary, yielding even more methods.
Generally speaking, if behavior is modeled in this way, there is gained the
possibility of placing the responsibility of setting a flag in the proposed
Strings object, or indeed more complex behavior, on the enum instance. If
all behavioral options were expressed in this way, the actual builder API
might consist of quite a limited number (in the sense of method names) of
(perhaps heavily overloaded) methods.
Matt
--
> OpenPGP: https://hasan.d8u.us/openpgp.asc
> If you wish to request my time, please do so using
> *bit.ly/hd1AppointmentRequest
> *.
> Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
> *.
>
> >Sent
> from my mobile device
> Envoye de mon portable
>
Re: [lang] Considering a new String utility class
Yes, an enum is better than a mystery boolean.
Gary
On Thu, Mar 16, 2023, 00:18 Matt Benson wrote:
> On Wed, Mar 15, 2023 at 11:10 PM Hasan Diwan
> wrote:
>
> > On Wed, 15 Mar 2023 at 20:55, Matt Benson wrote:
> >
> > > > > > > Any thoughts?
> > >
> >
> > Something like:
> >
> > > StringUtils2.ignoreCase() /* makes the next functions case insensitive
> > */.respectCase(). * back to case-sensitive */
> >
> >
> What about something like:
>
> enum CaseSensitivity { CS, NONCS }
>
> with(CaseSensitivity o);
>
> Matt
>
>
> > ? -- H
> >
> > --
> > OpenPGP: https://hasan.d8u.us/openpgp.asc
> > If you wish to request my time, please do so using
> > *bit.ly/hd1AppointmentRequest
> > *.
> > Si vous voudrais faire connnaisance, allez a *
> bit.ly/hd1AppointmentRequest
> > *.
> >
> > > >Sent
> > from my mobile device
> > Envoye de mon portable
> >
>
Re: [VOTE] Release Apache Commons JEXL 3.3 based on RC1
Unfortunately, more testing revealed a regression and a bug. RC1 fails, RC2 will be proposed momentarily. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CANCEL][VOTE] Release Apache Commons JEXL 3.3 based on RC1
Late tests reopened JEXL-393 and discovered a regression (JEXL-394). RC2 will be proposed momentarily. Sorry.
Re: [VOTE] Release Apache Commons JEXL 3.3 based on RC1
Would you very briefly outline the bug FTR? TY! Gary On Thu, Mar 16, 2023, 15:46 Henri Biestro wrote: > > Unfortunately, more testing revealed a regression and a bug. > RC1 fails, RC2 will be proposed momentarily. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
