Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-13 Thread Department 8
No problem this was actually my first time engaging in any Open source
contribution, so it was a good way to know what should be done in quality
and quantity for any open source contribution, so thanks for helping me
learn as well.

On Thu, Jun 13, 2024, 19:13 Gary D. Gregory  wrote:

> 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  wrote:
> >
> > > See also my comment in the PR.
> > >
> > > Gary
> > >
> > > On Wed, Jun 12, 2024, 1:22 PM Department 8 
> > > 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  >
> > > > 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
>
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-13 Thread Gary D. Gregory
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  wrote:
> 
> > See also my comment in the PR.
> >
> > Gary
> >
> > On Wed, Jun 12, 2024, 1:22 PM Department 8 
> > 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 
> > > wrote:
> > >
> > > > On Wed, 12 Jun 2024 at 18:03, Department 8 
> > > > 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  > >
> > > > > 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



Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Department 8
I see the point you are making. Thanks for taking the time to review it.

On Wed, Jun 12, 2024, 23:30 Gary Gregory  wrote:

> See also my comment in the PR.
>
> Gary
>
> On Wed, Jun 12, 2024, 1:22 PM Department 8 
> 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 
> > wrote:
> >
> > > On Wed, 12 Jun 2024 at 18:03, Department 8 
> > > 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  >
> > > > 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?
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Gary Gregory
See also my comment in the PR.

Gary

On Wed, Jun 12, 2024, 1:22 PM Department 8  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 
> wrote:
>
> > On Wed, 12 Jun 2024 at 18:03, Department 8 
> > 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 
> > > 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  >
> > > > 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?
> > > >>
> > > >>
> > > >>
> > >
> >
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Department 8
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  wrote:

> On Wed, 12 Jun 2024 at 18:03, Department 8 
> 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 
> > 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 
> > > 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?
> > >>
> > >>
> > >>
> >
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Alex Herbert
On Wed, 12 Jun 2024 at 18:03, Department 8  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 
> 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 
> > 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?
> >>
> >>
> >>
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Department 8
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?

On Wed, 12 Jun 2024 at 22:29, Department 8  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 
> 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?
>>
>>
>>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Department 8
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  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?
>
>
>


Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-12 Thread Alex Herbert
Hi,

On Wed, 12 Jun 2024 at 17:23, Department 8  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?
>

Is this different from:

public static boolean isAnyNotBlank(final CharSequence... css) {
return !isAllBlank(css);
}

If the implementation is as above then you add an extra method that must be
invoked using more characters than:

!StringUtils.isAllBlank(...)

This doesn't seem helpful. If there is more logic to the method then it may
be worth considering.

There are also the other methods that could be similarly negated:

isAllEmpty
isAllLowerCase
isAllUpperCase

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.

Alex