Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easier way to detect if object is null #8598

Closed
sethladd opened this issue Feb 18, 2013 · 8 comments
Closed

Easier way to detect if object is null #8598

sethladd opened this issue Feb 18, 2013 · 8 comments
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant core-n P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@sethladd
Copy link
Contributor

In a dynamic scripting language, typing this feels weird:

if (obj != null)

I'd much rather do this:

if (obj)

But because I don't expect that to happen, might I suggest the following:

if (obj.isNull)

This is similar to the helpers we have like isEven and isEmpty.

Here's how I think isNull can be added:

Object.isNull returns false, unless the instance is of the class Null, in which case it returns true. Much like runtimeType is final, I think 'final get isNull' can be added. I'd go as far as to say it is a compile-time warning if isNull is implemented by a class.

I admit this is an aesthetic thing, but aesthetics matter.

Slight bonus, this drives home the point that null is an object.

@DartBot
Copy link

DartBot commented Nov 21, 2014

This comment was originally written by bryonmarks...@gmail.com


Perhaps slightly different, but very much related, I'd love to have Null-Conditional Operators (http://msdn.microsoft.com/en-us/magazine/dn802602.aspx)

@DartBot
Copy link

DartBot commented Nov 22, 2014

This comment was originally written by @Emasoft


Yes, +1 for null-conditional operators and null-propagation in Dart.

That would solve many problems and would make the code much more concise.

@kevmoo
Copy link
Member

kevmoo commented Nov 26, 2014

Removed Area-Library label.
Added Area-Language label.

@gbracha
Copy link
Contributor

gbracha commented Dec 22, 2014

I am sympathetic to the idea of Object.isNull.

This is really a library issue: adding get isNull => false to Object, and a version that returns true to Null.
One caveat: a method can be overridden. This IMO a good thing, as proxies for null can work seamlessly.
However, we have all of 5 methods on Object which is really nice. So the bar for adding anything to Object is really high.

Of course, adding methods to Object at this stage is risky, since someone out in the universe may have defined isNull already. So I doubt if we'll do this before 2.0.


Set owner to @gbracha.
Removed Area-Language label.
Added Area-LanguageFeature, Accepted labels.

@lrhn
Copy link
Member

lrhn commented Mar 15, 2015

I don't think this is a good idea.
We have already special-cased null in == checks, so adding another way to do the same thing, and one that can be overridden at that, seems unnecessary.

I agree that it's a matter of aesthetics, which makes it completely subjective, but I subjectively disagree on the aesthetics being better.
(If we add it, we should also have isNotNull, which doesn't make it better).


Removed Area-LanguageFeature label.
Added Area-Library label.

@kevmoo kevmoo added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug and removed accepted labels Feb 29, 2016
@lrhn lrhn added the core-m label Aug 11, 2017
@floitschG floitschG added core-n and removed core-m labels Aug 29, 2017
@matanlurey matanlurey added the closed-obsolete Closed as the reported issue is no longer relevant label Jun 19, 2018
@jibiel
Copy link

jibiel commented Dec 13, 2020

@lrhn Apologies for gravedigging but how isNotNull is any different from introducing isNotEmpty sugar for length > 0?

It's weird having to write != null in a high level, mostly object-oriented modern language like it's JS 90s or something.

It's looks strange in a mostly-words-dot-notations-and-maps-code (Flutter) and sometimes it's visually harder to read as it breaks the flow of it.

@jodinathan
Copy link

@lrhn Apologies for gravedigging but how isNotNull is any different from introducing isNotEmpty sugar for length > 0?

It's weird having to write != null in a high level, mostly object-oriented modern language like it's JS 90s or something.

It's looks strange in a mostly-words-dot-notations-and-maps-code (Flutter) and sometimes it's visually harder to read as it breaks the flow of it.

that can be easily done with extension methods: https://dartpad.dartlang.org/ed0a241f8e6cb9d8b5d77f889f7800b1

extension AdvObj on Object {
  bool get isNotNull => this != null;
}

@dart-lang dart-lang locked as resolved and limited conversation to collaborators Dec 13, 2020
@lrhn
Copy link
Member

lrhn commented Dec 14, 2020

There are two significant differences between .isNull/isNotNull and isEmpty/isNotEmpty.

The isEmpty differs from .length == 0 in that it doesn't need to compute the length. For iterables, computing the length might take time linear in the number of elements (it really has to count them one by one), whereas isEmpty/isNotEmpty can be done in constant time for most iterables (a .where or expand iterable might need more since they can need to iterate elements which do not provide any elements for the result). The isNull has no such advantage over == null.
It's also more readable because it says the word "empty" rather than letting you infer that from the combination of length and 0. The isNull has no such advantage over == null, which literally reads as "is null".

Second, the == null is special in that the Null Safety feature allows it to promote a variable to being non-null.
An extension method like .isNotNull won't do that, so I highly recommend not introducing such extension methods. They will be useless very soon.
Example: String? x = ...; if (x != null) number += x.length; is valid, String? x = ...; if (x.isNotNull) number += x.length; is a compile-time error.

In some cases, the check for null can be combined with the operation to do in the null/non-null case, like x ??= "a"; or x?.length. In others, they can't, and you need to do the == null.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant core-n P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

9 participants