On Wed, Mar 15, 2023 at 9:47 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> On Wed, Mar 15, 2023 at 9:11 AM Matt Benson <mben...@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 <melloware...@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-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 > >
