You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far we decided not to make every Java object nullable in Dart because without additional annotations, every Java object can be nullable and the resulting code will be full of null-checks. However, we may even prefer this because then we can't forget to do if (nullableJObject.isNull) as the type system prevents us.
I recently made fromReference internal, so now the only way to pass null without hitting a lint is the verbose JObject.fromReference(jNullReference).as(Foo.type)!
We can make all methods accept Foo? and if null is passed, we interpret that as a Java object with a reference of nullptr.
If we generate all objects as nullable, then this happens automatically!
We can expose a jnull constant which users have to cast to the right object jnull.as(Foo.type)
without additional annotations, every Java object can be nullable and the resulting code will be full of null-checks
From what I've seen in our own plugin development, annotating the nullability of everything public is best pratice (for interop with Kotlin, I assume). Given that annotations to solve this problem exist and are readily available I would think we would want to optimize for making better type safety easier, rather than optimizing for the ease of use of code that's not annotated.
Also, without annotations, the correct interpretation in a language like Dart is (as you said) that everything can be nullable. If everything could be nullable, then code being full of null checks is correct. So that doesn't actually seem like a problem to me (in the case of non-annotated code that can't be annotated for whatever reason).
So far we decided not to make every Java object nullable in Dart because without additional annotations, every Java object can be nullable and the resulting code will be full of null-checks. However, we may even prefer this because then we can't forget to do
if (nullableJObject.isNull)
as the type system prevents us.I recently made
fromReference
internal, so now the only way to passnull
without hitting a lint is the verboseJObject.fromReference(jNullReference).as(Foo.type)
!Foo?
and ifnull
is passed, we interpret that as a Java object with a reference ofnullptr
.jnull
constant which users have to cast to the right objectjnull.as(Foo.type)
wdyt @liamappelbe @dcharkes @stuartmorgan?
The text was updated successfully, but these errors were encountered: