On Tuesday, January 6, 2015 7:38:00 PM UTC+10, Milan Bouchet-Valat wrote:
>
> Le lundi 05 janvier 2015 à 19:16 -0800, [email protected] <javascript:> 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}()`.
>
Yeah, (==){T}(a::Nullable{T}, b::T) should be able to be defined as
!isnull(a) && get(a) == b
Cheers
Lex
>
> 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
>
