On 2024/06/13 00:22:13 Department 8 wrote:
> I see the point you are making. Thanks for taking the time to review it.
And thank you for engaging with us on improving this component! :-)
Gary
>
> On Wed, Jun 12, 2024, 23:30 Gary Gregory <garydgreg...@gmail.com> wrote:
>
> > See also my comment in the PR.
> >
> > Gary
> >
> > On Wed, Jun 12, 2024, 1:22 PM Department 8 <manstein.fe...@gmail.com>
> > wrote:
> >
> > > Haha! It was in fact because of other methods that have simple negation
> > > that I thought maybe giving a PR would be Okay :)
> > >
> > > I think that many times, it is the Boolean Logic that may trivial for us,
> > > but for some who may be using them to have a utility methods like
> > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> > > code to a good extent. So it is more of a clean fix for them.
> > >
> > > Another way may be to - do a for loop on all of them and once you find
> > > NotBlank to be true you return true, else iterate till end and return
> > false
> > > (the actual negated logic of isAllBlank) but that would mean for the
> > > clients of the API to write that helper function for themselves. So this
> > > can provide an easy wrap.
> > >
> > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert <alex.d.herb...@gmail.com>
> > > wrote:
> > >
> > > > On Wed, 12 Jun 2024 at 18:03, Department 8 <manstein.fe...@gmail.com>
> > > > wrote:
> > > >
> > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > >
> > > > > I had done just for isAllEmpty and isAllBlank.
> > > > >
> > > > > Can you tell me more on what can be done, when you said the
> > following:
> > > > >
> > > > > If you are simply negating the result of another method then this use
> > > > case
> > > > > may be better served with addition of a suitable example to the
> > javadoc
> > > > of
> > > > > the method you are negating.
> > > > >
> > > > > Like do you want me to add examples of use-cases?
> > > > >
> > > >
> > > > I've seen the PR. The new methods are a simple boolean negation of
> > > existing
> > > > methods. So these are not adding functionality that cannot be achieved
> > > with
> > > > the current API.
> > > >
> > > > Note that a quick check in StringUtils for 'return !' finds these
> > > methods:
> > > >
> > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > > return !isAnyBlank(css);
> > > > }
> > > >
> > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > return !isAnyEmpty(css);
> > > > }
> > > >
> > > > There are two others for single CharSequence args as well: isNotBlank
> > and
> > > > isNotEmpty.
> > > >
> > > > So it is not without precedent to add more methods that are simple
> > > > negations. However we have to consider if this is code bloat, or if the
> > > > addition of simple negation methods is so useful that it warrants
> > > > inclusion. I would currently consider this as redundant given the lack
> > of
> > > > actual logic in the methods.
> > > >
> > > > Alex
> > > >
> > > >
> > > > >
> > > > > On Wed, 12 Jun 2024 at 22:29, Department 8 <manstein.fe...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > I just realized the subject name is bad. But here are the two small
> > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > >
> > > > > > Please find the pull request as here:
> > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hey!
> > > > > >>
> > > > > >> Recently when using StringUtils in one of our projects I had felt
> > > the
> > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > >>
> > > > > >> I was able to achieve this using the negation of isAllBlank, so I
> > am
> > > > > >> thinking of introducing the code with all tests.
> > > > > >>
> > > > > >> It is ready to be pushed to PR. Do let me know what you think and
> > > what
> > > > > >> are the next steps for the same?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
