The problem is not so much when you are (potentially) generating and handling
null dates in your own code, but how one interacts with library code that may
or may not return a null. Especially in a dynamically typed language, in the
absence of a Nullable type the only way to determine if a method *might* return
null is to check the documentation.
That said, I think dealing with Nullable’s could be made more convenient in
Julia. For example, Swift’s `if let` construct gracefully handles checking
null-ness and unwrapping a nullable type in one go. This would change your code
to something like:
leapDay(yr) = isleapyear(yr) ? Nullable(Date(yr,2,29)) : Nullable{Date}()
# …
if let ld = leapDay(yr)
doy = dayofyear(ld)
# …
Obviously since `let` is already in use for other purposes in Julia, this exact
example wouldn’t work. I’m sure with more experience and examples like this,
though, patterns will emerge. (For one thing, @if-let should be trivially
implementable as a macro.)
On February 10, 2016 at 06:28:52, Michael Landis ([email protected])
wrote:
missed a paren above (for the people that are going to past the code into a
shell and try it out) - something that I am not doing. Still, this is closer:
# wishful thinking...
using Dates;
leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
if ! leapDay
doy = dayofyear( leapDay )
... clean and concise (thought that was the point), but we get
leapDay = isleapyear (yr)? Nullable {Date} (Date (yr, 2:29)): Nullable {Date}
()
if ! isnull( leapDay )
doy = dayofyear( get(leapDay) )
On Tue, Feb 9, 2016 at 8:22 PM, Michael Landis <[email protected]> wrote:
# wishful thinking...
using Dates;
leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
if ! leapDay
dow = dayofyear( leapDay )
... clean and concise (thought that was the point), but we get
leapDay = isleapyear(yr) ? Nullable{Date}( Date(yr,2,29) : Nullable{Date}()
if ! isnull( leapDay )
dow = dayofyear( get(leapDay) )
...
If I am dumb enough to forget to check for a null date, I deserve the exception
- the code would be wrong. Making me type two or three times as many
characters, obscuring what is actually going on, ... all to eliminate
NullPointerExceptions? I have to write exception free code anyway, so all I
have 'gained' is a lot of superfluous verbosity. I'm going to side with
salience over verbosity every time. The type safe argument just doesn't sell
me, sorry.