I'd like to suggest changing the isnull::Bool
field of Nullable
to a hasvalue::Bool
field with the opposite meaning. Indeed, all languages and formats I could find use this convention. Following the most common convention is generally a good idea, and it's particularly useful when creating NullableArrays
from binary formats like Feather.
Of course, this would be a breaking change, but it would only affect code which does not use the public isnull()
method. Since that method is a simple accessor to the eponymous field, there's no reason to access the field directly. Potential breakage would easily be fixed before 0.6 is released by changing x.isnull
to isnull(x)
, which works since Julia 0.4.
Here's a short survey of what other software does in that regard:
Nullable
type has an HasValue
field.Option
type has an isDefined
method.Valid
field.NULL
is marked via serial type 0
(equivalent to false
in most languages).0
bit (again equivalent to false
in most languages) to denote a null
.CC: @johnmyleswhite @quinnj @davidagold
R has is.na()
, but I find myself almost exclusively doing !is.na(x)
Note that I'm not talking about changing the isnull()
function here, only the underlying implementation.
Oh. Well, maybe changing the function is something to consider as well?
I'm on board with this because I think it will simplify using the internals for fast math: you can treat these as frequency-count weights and do things like x.value * x.hasvalue
as long as you guarantee the absence of NaN
.
Oh. Well, maybe changing the function is something to consider as well?
I'd rather discuss this somewhere else. If you open an issue, please also make a survey of what other languages do (it seems to me isnull()
is the most common pattern).
Most helpful comment
I'm on board with this because I think it will simplify using the internals for fast math: you can treat these as frequency-count weights and do things like
x.value * x.hasvalue
as long as you guarantee the absence ofNaN
.