Interesting, but I don’t understand why null should be avoided in these cases. Null means nothing, means the absence of something. So when a user input is left or reset to null, it means the exact same thing as he “UNKNOWN” implemented by the author.
One advantage I can think of: you simplify the type from nullable(Weather) to just Weather. So if you ever access a weather instance’s attributes, you can cover all cases with myweather.icon, and you won’t need to do a null check first.
It’s more a question of where you prefer to do that check. Note that the when statement contains three such checks and assignments of UNKNOWN, so the conversion/sanitisation has to happen somewhere.
Part of this may also be old scars of my own; having worked with APIs written by people who use non-null-safe languages, I’ve often encountered input which is both nullable and has an UNKNOWN value.
Note that the when statement contains three such checks and assignments of UNKNOWN, so the conversion/sanitisation has to happen somewhere.
That when statement is the point where UI info enters the system, and gets converted into a value. I agree that if the user can check zero checkboxes, that possibility needs to be recorded, either as weather.UNKNOWN or as null.
But actually I wasn’t thinking of the place where this.weather gets created, but that the benefits are possible later on, when this.weather gets used. If the programmer associates data/attributes (or behaviour/methods) with each weather variant, then with weather.UNKNOWN they can store relevant data in its attributes; with null they have to store that data in the handling code. This is the kind of contrast I was thinking of:
enum class Weather {
UNKNOWN {
var icon: String = "□",
},
// and so on for SUNNY, CLOUDY, and RAINY
}
// Later on, we display a mood entry with a weather icon
myIcon = myEntry.weather.icon
versus
enum class Weather {
SUNNY {
var icon: String = "🌞"
},
// and so on for CLOUDY and RAINY
}
// Later on, we display a mood entry with a weather icon
myIcon = if (myEntry.weather != null) myEntry.weather.icon else "□"
Part of this may also be old scars of my own; having worked with APIs written by people who use non-null-safe languages, I’ve often encountered input which is both nullable and has an UNKNOWN value.
Oh yes, I can imagine that would leave scars. For a null-dangerous language, how would you feel about having an UNKNOWN variant anyway, so you can encode fallback data in the same way as data for known weather types? I’m thinking of something like Variant 2 over Variant 3, below.
// Variant 1: don't use this, it'll blow up if weather is unexpectedly null
// myIcon = myEntry.weather.icon
// Variant 2: have an UNKNOWN variant to store data on
myIcon = if (myEntry.weather != null) myEntry.weather.icon
else Weather.UNKNOWN.icon
// Variant 3: null + UNKNOWN is redunant,
// prefer having only `null` though it means storing data elsewhere
myIcon = if (myEntry.weather != null) myEntry.weather.icon
else "□" // or config.unknownWeatherIcon
A null value must be dealt with at some point in time, and that point is a design choice. You can eliminate it early, in the when statement, or you can do it at rendering time, as demonstrated by your unsafe examples at the bottom of your comment.
You could also refactor this so that you store the weather (or its absence) as a pure “model” object, whereas the combined storage of weather (whether known or unknown) and icon can be regarded as a “view model” object. The pure model object is easily serialised or persisted since it’s just an enumeration, and can be converted into the view model object as needed.
Mind you, I envisioned a null weather to have no icon at all, resulting in hiding the entire GUI element. In that case, using the language’s built-in hnalding of null presents itself as a natural option.
Interesting, but I don’t understand why
nullshould be avoided in these cases. Null means nothing, means the absence of something. So when a user input is left or reset tonull, it means the exact same thing as he “UNKNOWN” implemented by the author.One advantage I can think of: you simplify the type from
nullable(Weather)to justWeather. So if you ever access a weather instance’s attributes, you can cover all cases withmyweather.icon, and you won’t need to do a null check first.It’s more a question of where you prefer to do that check. Note that the
whenstatement contains three such checks and assignments ofUNKNOWN, so the conversion/sanitisation has to happen somewhere.Part of this may also be old scars of my own; having worked with APIs written by people who use non-null-safe languages, I’ve often encountered input which is both nullable and has an
UNKNOWNvalue.That
whenstatement is the point where UI info enters the system, and gets converted into a value. I agree that if the user can check zero checkboxes, that possibility needs to be recorded, either asweather.UNKNOWNor asnull.But actually I wasn’t thinking of the place where
this.weathergets created, but that the benefits are possible later on, whenthis.weathergets used. If the programmer associates data/attributes (or behaviour/methods) with each weather variant, then withweather.UNKNOWNthey can store relevant data in its attributes; withnullthey have to store that data in the handling code. This is the kind of contrast I was thinking of:versus
Oh yes, I can imagine that would leave scars. For a null-dangerous language, how would you feel about having an UNKNOWN variant anyway, so you can encode fallback data in the same way as data for known weather types? I’m thinking of something like Variant 2 over Variant 3, below.
A
nullvalue must be dealt with at some point in time, and that point is a design choice. You can eliminate it early, in thewhenstatement, or you can do it at rendering time, as demonstrated by your unsafe examples at the bottom of your comment.You could also refactor this so that you store the weather (or its absence) as a pure “model” object, whereas the combined storage of weather (whether known or unknown) and icon can be regarded as a “view model” object. The pure model object is easily serialised or persisted since it’s just an enumeration, and can be converted into the view model object as needed.
Mind you, I envisioned a
nullweather to have no icon at all, resulting in hiding the entire GUI element. In that case, using the language’s built-in hnalding ofnullpresents itself as a natural option.I bet this guy would like typed functional programming
She’s not a guy, though.
You mean like Kotlin?