Le mardi 06 janvier 2015 à 04:38 -0800, [email protected] a écrit :
>
>
> 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] 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
I'd consider this definition (which is different from the ones I
suggested above) as unsafe: if `a` is `null`, then you silently get
`false`. Better provide additional safety by either returning a
`Nullable`, or raising an exception.
>
> 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
