Le lundi 05 janvier 2015 à 19:16 -0800, ele...@gmail.com a écrit :
> My reasoning for Nullable{T} is that it is type stable. Taking your
> example, None and Int would be different type objects, introducing a
> type instability and potential performance penalty. But Nullable{T}
> is always type Nullable{T} and get(Nullable{T}) is always type T.
> Allowing Nullable{T} to decay into T would re-introduce the type
> instability.
Right. But that doesn't mean `Nullable(3) == 3` shouldn't return `true`.
This operation could be allowed, provided that `Nullable{Int}() == 3`
raised a `NullException` or returned `Nullable{Bool}()`.
Regarding the original question:
> On Tuesday, January 6, 2015 12:03:24 PM UTC+10, Seth wrote:
> I'm trying to figure out how (and under what circumstances)
> one would use Nullable. That is, it seems that it might be
> valuable when you don't know whether the value/object exists
> (sort of like Python's None, I guess), but then something like
> "Nullable(3) == 3" returns false, and that sort of messes up
> how I'm thinking about it.
>
>
> The code I'd imagine would be useful would be something like
>
>
> function foo(x::Int, y=Nullable{Int}()) # that is, y defaults
> to python's "None" but is restricted to Int
> if !isnull(y)
> return x+y # x + get(y) works, but why must we invoke
> another method to get the value?
> else
> return 2x
> end
> end
>
>
> I'm left wondering why it wasn't reasonable to allow y to
> return get(y) if not null, else raise a NullException,
The question is how you define "return". In the strict sense, if you
write `return y`, then `y` must be returned, not `get(y)`, or the Julia
language would really be a mess.
That said, with return type declarations, if `foo()::Int` allowed
stating that `foo()` always returns an `Int`, then `y` could
automatically be converted to an `Int`, raising an exception if it's
`null`. But that merely allows you to type `return y` instead of
`return get(y)`, so not a big deal.
Finally, there's the question of whether `x + y` should be allowed to
mean `x + get(y)`. That's debatable, but I think a more useful behavior
would be to make it equivalent to
`isnull(y) ? Nullable(x + get(y)) : Nullable{Int}()`. That would allow
handling the possibility of missingness only when you actually want to
get an `Int` from a `Nullable{Int}`.
This has been discussed more generally for any function call at
https://github.com/JuliaLang/julia/pull/9446
> and the conclusion I'm coming to is that I don't understand
> the concept of Nullable yet. Any pointers?
>
Regards
