Language: .isNotNull AND .isNotNullOrEmpty

[jamiethain]

I write a significant amount of Dart Code that form wrappers around other code including but not limited to Column's and other properties.

null to me is a special condition when you have the control in some form of state where your not modifying the variable or property. You intend it to be null, however there is also therefore a considerable amount of null and empty checking at the dart level.

Class
method ({String someParamater, ClassMech someClassMech)

InLineFunction
function ({String someParamater, ClassMech someClassMech)

Either way even when setting class variables I tend to do a lot of this type of code,
if (someParameter != null && someParameter.isNotEmpty )
{
someParameter = someParameterManipulation(someParameter);
someList.add(someParameter)
}

Maybe there is a shortcut I don't already understand but this could be cut to

if (someParameter.isNotNullOrEmpty)
someList.add(someParameterManipulation(someParameter)

Of course it would be added in Dart Core.

Or is there a way I can add it just for me.

Describe the new syntax or language feature you'd like to see incorporated into
Dart. Ideally you can relate this to a request issue filed separately.

[tatumizer]

You can do it with the upcoming extension methods, but it would be a bit type-unsafe (probably tolerable)

extension MyExt<T> on T {
  bool get isEmptyOrNull {
    if (this == null) {
      return true;
    } else if (this is String) {
      return (this as String).isEmpty;  // compiler can't figure out the type for some reason
    } else {
      throw CastError();
    }
  }
  bool get isNotEmptyOrNull => !this.isEmptyOrNull; 
}
main() {
  print(null.isEmptyOrNull);     // true
  print(null.isNotEmptyOrNull);  // false
  print("".isEmptyOrNull);       // true
  print("".isNotEmptyOrNull);    // false
  print("x".isEmptyOrNull);      // false
  print("x".isNotEmptyOrNull);   // true
  print(5.isEmptyOrNull);        // Uncaught Error: Instance of 'CastError'
  print(5.isNotEmptyOrNull);     // Uncaught Error: Instance of 'CastError'
}

You have to write extension MyExt<T> on T rather than more obvious extension MyExt on Object because the latter will (probably) stop working after NNBD release.

[jamiethain]

Ok that will be great -- I would like it for every type though.

On Sat, Nov 30, 2019 at 7:15 PM Tatumizer [e-mail] wrote:

You can do it with the upcoming extension methods, but it would be a bit
type-unsafe (probably tolerable)

extension MyExt on T {
bool get isEmptyOrNull {
if (this == null) {
return true;
} else if (this is String) {
return (this as String).isEmpty; // compiler can't figure out the type for some reason
} else {
throw CastError();
}
}
bool get isNotEmptyOrNull => !this.isEmptyOrNull;
}
main() {
print(null.isEmptyOrNull); // true
print(null.isNotEmptyOrNull); // false
print("".isEmptyOrNull); // true
print("".isNotEmptyOrNull); // false
print("x".isEmptyOrNull); // false
print("x".isNotEmptyOrNull); // true
print(5.isEmptyOrNull); // Uncaught Error: Instance of 'CastError'
print(5.isNotEmptyOrNull); // Uncaught Error: Instance of 'CastError'
}

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/language/issues/714?email_source=notifications&email_token=AMOCL6EOIB22WZ47B2NXD33QWL6YPA5CNFSM4JTHMFF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQWW4I#issuecomment-560032625,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMOCL6EINQ3YTZZXK5GKXHTQWL6YPANCNFSM4JTHMFFQ
.

[lrhn]

@tatumizer

You have to write extension MyExt<T> on T rather than more obvious extension MyExt on Object because the latter will (probably) stop working after NNBD release.

You can write:

extension MyExt on dynamic { ... }

now and it will keep working post-NNBD. Just avoid using that this is dynamic to do dynamic invocations - promoting to String like you do is fine.

[lrhn]

A different approach is:

extension EmptyString on String {
  bool get isNullOrEmpty => this == null || this.isEmpty;
}
extension EmptyIterable on Iterable {
  bool get isNullOrEmpty => this == null || this.isEmpty;
}
extension EmptyMap on Map {
  bool get isNullOrEmpty => this == null || this.isEmpty;
}

That covers all strings, iterables and maps, which are all the types (IIRC) which have a synchronous isNotEmpty in the platform libraries.

As a design principle, I try to avoid having fields or return values that can be either null or empty, at least if that means the same thing. Just return a constant empty list instead of null, and the code never needs to check for null, it can always do .isEmpty directly.

[tatumizer]

@lrhn: Will extension EmptyString on String be applicable to String? and Null types after NNBD?

[munificent]

Will extension EmptyString on String be applicable to String? and Null types after NNBD?

No, but this extension would apply:

extension EmptyString on String? {
  bool get isNullOrEmpty => this == null || this.isEmpty;
}

[lrhn]

As Bob says, extension declarations need to be migrated to NNBD like all other code.

In the interregnum between non-NNBD and NNBD, non-migrated code will still be usable from migrated code, and a non-migrated extension Foo on String will apply to String? expressions in a migrated library.