You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2023/03/15 12:58:28 UTC
[lang] Considering a new String utility class
PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
method and tests cases" keep popping up from time to time.
My preference is to stop adding APIs that are variations of other APIs
based on case sensitivity (and Charset, Locale, and so on).
Instead, I can see adding a new String utility class that tracks such
attributes on its instance such that you'd say something like:
- Strings.caseSensitive().someOperation(...)
- Strings.caseInsensitive().someOperation(...).
The 2 above would access pre-built instances probably. A builder would
let you build an instance that your app can cache:
Strings.builder().setCaseSensitivity(true).setCharset(...).build();
An instance of Strings or whatever to call such a class would track
case sensitivity, a Locale, and maybe an input and output Charset, I'm
not 100% sure yet. But you get the idea I hope.
Any thoughts?
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Considering a new String utility class
Posted by Xeno Amess <xe...@gmail.com>.
Otherwise I doubt the cost...
________________________________
From: Xeno Amess <xe...@gmail.com>
Sent: Monday, March 20, 2023 7:00:14 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [lang] Considering a new String utility class
I agree if it doesn't hurt more than 5% performance.
________________________________
From: Peter Verhas <pe...@verhas.com>
Sent: Monday, March 20, 2023 4:16:17 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [lang] Considering a new String utility class
A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.
I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.
On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory <ga...@gmail.com> wrote:
> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Peter Verhas
peter@verhas.com
t: +41791542095
skype: verhas
Re: [lang] Considering a new String utility class
Posted by Xeno Amess <xe...@gmail.com>.
I agree if it doesn't hurt more than 5% performance.
________________________________
From: Peter Verhas <pe...@verhas.com>
Sent: Monday, March 20, 2023 4:16:17 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [lang] Considering a new String utility class
A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.
I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.
On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory <ga...@gmail.com> wrote:
> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Peter Verhas
peter@verhas.com
t: +41791542095
skype: verhas
Re: [lang] Considering a new String utility class
Posted by Peter Verhas <pe...@verhas.com>.
A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.
I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.
On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory <ga...@gmail.com> wrote:
> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Peter Verhas
peter@verhas.com
t: +41791542095
skype: verhas
Re: [lang] Considering a new String utility class
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory <ga...@gmail.com> wrote:
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
Agreed 100%, because this would allow to reduce static methods to an
absolute minimum
(The builder provider(s).)
Jochen
--
Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Considering a new String utility class
Posted by Hasan Diwan <ha...@gmail.com>.
+1
On Wed, 15 Mar 2023 at 05:58, Gary Gregory <ga...@gmail.com> wrote:
> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
OpenPGP: https://hasan.d8u.us/openpgp.asc
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
<http://bit.ly/hd1AppointmentRequest>*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
<http://bit.ly/hd1AppointmentRequest>*.
<https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1>Sent
from my mobile device
Envoye de mon portable
Re: [lang] Considering a new String utility class
Posted by Gary Gregory <ga...@gmail.com>.
Yes, an enum is better than a mystery boolean.
Gary
On Thu, Mar 16, 2023, 00:18 Matt Benson <mb...@apache.org> wrote:
> On Wed, Mar 15, 2023 at 11:10 PM Hasan Diwan <ha...@gmail.com>
> wrote:
>
> > On Wed, 15 Mar 2023 at 20:55, Matt Benson <mb...@apache.org> 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
> > <http://bit.ly/hd1AppointmentRequest>*.
> > Si vous voudrais faire connnaisance, allez a *
> bit.ly/hd1AppointmentRequest
> > <http://bit.ly/hd1AppointmentRequest>*.
> >
> > <https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
> > >Sent
> > from my mobile device
> > Envoye de mon portable
> >
>
Re: [lang] Considering a new String utility class
Posted by Matt Benson <mb...@apache.org>.
On Thu, Mar 16, 2023, 3:15 AM Hasan Diwan <ha...@gmail.com> 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
> <http://bit.ly/hd1AppointmentRequest>*.
> Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
> <http://bit.ly/hd1AppointmentRequest>*.
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
> >Sent
> from my mobile device
> Envoye de mon portable
>
Re: [lang] Considering a new String utility class
Posted by Hasan Diwan <ha...@gmail.com>.
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
<http://bit.ly/hd1AppointmentRequest>*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
<http://bit.ly/hd1AppointmentRequest>*.
<https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1>Sent
from my mobile device
Envoye de mon portable
Re: [lang] Considering a new String utility class
Posted by Matt Benson <mb...@apache.org>.
On Wed, Mar 15, 2023 at 11:10 PM Hasan Diwan <ha...@gmail.com> wrote:
> On Wed, 15 Mar 2023 at 20:55, Matt Benson <mb...@apache.org> 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
> <http://bit.ly/hd1AppointmentRequest>*.
> Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
> <http://bit.ly/hd1AppointmentRequest>*.
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
> >Sent
> from my mobile device
> Envoye de mon portable
>
Re: [lang] Considering a new String utility class
Posted by Hasan Diwan <ha...@gmail.com>.
On Wed, 15 Mar 2023 at 20:55, Matt Benson <mb...@apache.org> wrote:
> > > > > Any thoughts?
>
Something like:
> StringUtils2.ignoreCase() /* makes the next functions case insensitive
*/.respectCase(). * back to case-sensitive */
? -- H
--
OpenPGP: https://hasan.d8u.us/openpgp.asc
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
<http://bit.ly/hd1AppointmentRequest>*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
<http://bit.ly/hd1AppointmentRequest>*.
<https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1>Sent
from my mobile device
Envoye de mon portable
Re: [lang] Considering a new String utility class
Posted by Matt Benson <mb...@apache.org>.
On Wed, Mar 15, 2023 at 9:47 PM Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Mar 15, 2023 at 9:11 AM Matt Benson <mb...@apache.org> wrote:
> >
> > Agreed, Gary. Sounds promising. Maybe consider the "modern" terser
> builder
> > style a la AWS builders or such (i.e. since the "mutator" isn't a classic
> > Java beans mutator in any case, you can omit "set").
>
> So a setter is called foo(value) and the getter is called foo()? Kinda
> confusing IMO.
>
>
If you can't handle that, we could go for a fluent "with" syntax. But don't
overload the "set" idiom.
Matt
> Gary
>
> >
> > Matt
> >
> > On Wed, Mar 15, 2023, 8:06 AM Melloware <me...@gmail.com> wrote:
> >
> > > This sounds like a great idea!
> > >
> > >
> > > On 3/15/2023 8:58 AM, Gary Gregory wrote:
> > > > PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> > > > method and tests cases" keep popping up from time to time.
> > > >
> > > > My preference is to stop adding APIs that are variations of other
> APIs
> > > > based on case sensitivity (and Charset, Locale, and so on).
> > > >
> > > > Instead, I can see adding a new String utility class that tracks such
> > > > attributes on its instance such that you'd say something like:
> > > > - Strings.caseSensitive().someOperation(...)
> > > > - Strings.caseInsensitive().someOperation(...).
> > > >
> > > > The 2 above would access pre-built instances probably. A builder
> would
> > > > let you build an instance that your app can cache:
> > > > Strings.builder().setCaseSensitivity(true).setCharset(...).build();
> > > >
> > > > An instance of Strings or whatever to call such a class would track
> > > > case sensitivity, a Locale, and maybe an input and output Charset,
> I'm
> > > > not 100% sure yet. But you get the idea I hope.
> > > >
> > > > Any thoughts?
> > > >
> > > > Gary
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Considering a new String utility class
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Mar 15, 2023 at 9:11 AM Matt Benson <mb...@apache.org> wrote:
>
> Agreed, Gary. Sounds promising. Maybe consider the "modern" terser builder
> style a la AWS builders or such (i.e. since the "mutator" isn't a classic
> Java beans mutator in any case, you can omit "set").
So a setter is called foo(value) and the getter is called foo()? Kinda
confusing IMO.
Gary
>
> Matt
>
> On Wed, Mar 15, 2023, 8:06 AM Melloware <me...@gmail.com> wrote:
>
> > This sounds like a great idea!
> >
> >
> > On 3/15/2023 8:58 AM, Gary Gregory wrote:
> > > PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> > > method and tests cases" keep popping up from time to time.
> > >
> > > My preference is to stop adding APIs that are variations of other APIs
> > > based on case sensitivity (and Charset, Locale, and so on).
> > >
> > > Instead, I can see adding a new String utility class that tracks such
> > > attributes on its instance such that you'd say something like:
> > > - Strings.caseSensitive().someOperation(...)
> > > - Strings.caseInsensitive().someOperation(...).
> > >
> > > The 2 above would access pre-built instances probably. A builder would
> > > let you build an instance that your app can cache:
> > > Strings.builder().setCaseSensitivity(true).setCharset(...).build();
> > >
> > > An instance of Strings or whatever to call such a class would track
> > > case sensitivity, a Locale, and maybe an input and output Charset, I'm
> > > not 100% sure yet. But you get the idea I hope.
> > >
> > > Any thoughts?
> > >
> > > Gary
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Considering a new String utility class
Posted by Matt Benson <mb...@apache.org>.
Agreed, Gary. Sounds promising. Maybe consider the "modern" terser builder
style a la AWS builders or such (i.e. since the "mutator" isn't a classic
Java beans mutator in any case, you can omit "set").
Matt
On Wed, Mar 15, 2023, 8:06 AM Melloware <me...@gmail.com> wrote:
> This sounds like a great idea!
>
>
> On 3/15/2023 8:58 AM, Gary Gregory wrote:
> > PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> > method and tests cases" keep popping up from time to time.
> >
> > My preference is to stop adding APIs that are variations of other APIs
> > based on case sensitivity (and Charset, Locale, and so on).
> >
> > Instead, I can see adding a new String utility class that tracks such
> > attributes on its instance such that you'd say something like:
> > - Strings.caseSensitive().someOperation(...)
> > - Strings.caseInsensitive().someOperation(...).
> >
> > The 2 above would access pre-built instances probably. A builder would
> > let you build an instance that your app can cache:
> > Strings.builder().setCaseSensitivity(true).setCharset(...).build();
> >
> > An instance of Strings or whatever to call such a class would track
> > case sensitivity, a Locale, and maybe an input and output Charset, I'm
> > not 100% sure yet. But you get the idea I hope.
> >
> > Any thoughts?
> >
> > Gary
> >
> > ---------------------------------------------------------------------
> > 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
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Considering a new String utility class
Posted by Melloware <me...@gmail.com>.
This sounds like a great idea!
On 3/15/2023 8:58 AM, Gary Gregory wrote:
> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> ---------------------------------------------------------------------
> 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
For additional commands, e-mail: dev-help@commons.apache.org