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?
> > >>
> > >>
> > >>
> >
>
