:thinking_face: Is there a reason there is `.isNot...

# getting-started

[Pihentagy]

🤔
Is there a reason there is .isNotNull(), but no .isNotNullOrEmpty() for CharSequence? ?

[Joffrey]

isNotNullOrEmpty() is equivalent to isNotNull, though, because empty strings are not null. Did you mean isNotNullAndNotEmpty()?

[Joffrey]

Honestly I'm fine with !isNullOrEmpty(), the alternative seems either more verbose or more confusing

[Pihentagy]

Ah, well, negation…

I just remember IDEA correcting me when using !(x.isNull()) suggesting isNotNull()

What about simply .isNotEmpty() for CharSequence? returning false if the CharSequence is null?

[Joffrey]

Then it would become slightly incorrect. To be honest I'm not a big fan of extensions on nullable types in the first place, so maybe I'm not the right person to give my opinion on this, but I really think it's important that the name describes the null case.

[Joffrey]

isNeitherNullNorEmpty 😁

[James Richardson]

Don't forget with extension methods you can make whatever convenience functions you like:

fun String.whateverIWant(): Boolean = TODO("gotta think of something")

it doesn't have to go into the standard library, which creates a maintenance burden forever, you can tailor things to whatever you want. its easy to go overboard on these so do be thoughtful though!

[Rob Elliot]

I've been gently wondering if there's a case for a Field subtype of CharSequence which guarantees:
• not empty
• no leading or trailing whitespace
• no new line characters
A sort of half-way house between String and a specific microtype... then your cases for a reference of type Field? are reduced to null / not null, because empty and blank are impossible.

Seems to me there's a lot of code out there which is implicitly assuming a String typed reference adheres to those invariants.

[loke]

@Rob Elliot it can't be a subtype since CharSequence can be mutable.

[Rob Elliot]

String is a subtype of CharSequence, and String is immutable.

[loke]

Sorry, I thought you meant that any CharSequence satisfying these conditions would implicitly be a field.

[Rob Elliot]

No, I just meant a concrete subtype with some validating conversion functions from CharSequence to Field.

Argument against is that wherever you need it you probably have other validation requirements too (you almost certainly don't want it to be of potentially infinite length, for instance), so you arguably should be specifying a more specific String wrapping microtype.

Argument for is that loads of people can't be bothered to create String wrapping microtypes at all, they just use String, but might be persuadable to use a stdlib type of Field which would save a lot of empty / blank checking and redundant trimming or forgetting to trim.

[marlonlom]

What about isNotBlank() ?