Forgot to say Base.== returns bool, so this now makes == type unstable.
Type stable (in the context of Julia) means that the return type can be
statically inferred from the argument types. This means that + is type
stable, even though it returns a Float64 if the arguments are Float64 and
Le mercredi 07 janvier 2015 à 14:19 +0100, Tamas Papp a écrit :
On Wed, Jan 07 2015, Milan Bouchet-Valat nalimi...@club.fr wrote:
Le mercredi 07 janvier 2015 à 04:25 -0800, ele...@gmail.com a écrit :
A Nullable is immutable, its value isn't down the back of the couch
(which is my
Le mercredi 07 janvier 2015 à 04:25 -0800, ele...@gmail.com a écrit :
On Wednesday, January 7, 2015 9:36:28 PM UTC+10, Milan Bouchet-Valat wrote:
Le mardi 06 janvier 2015 à 05:27 -0800, ele...@gmail.com a écrit :
On Tuesday, January 6, 2015 10:43:16
On Wed, Jan 07 2015, Milan Bouchet-Valat nalimi...@club.fr wrote:
Le mercredi 07 janvier 2015 à 04:25 -0800, ele...@gmail.com a écrit :
A Nullable is immutable, its value isn't down the back of the couch
(which is my understanding of epistemological missingness, usually
applied to the TV
A Nullable is immutable, its value isn't down the back of the couch
(which is my understanding of epistemological missingness, usually
applied to the TV remote :), it can never get a value once its null.
That's not a technical question (immutable/mutable), but a conceptual
one. If
Le mardi 06 janvier 2015 à 05:27 -0800, ele...@gmail.com a écrit :
On Tuesday, January 6, 2015 10:43:16 PM UTC+10, Milan Bouchet-Valat wrote:
Le mardi 06 janvier 2015 à 04:38 -0800, ele...@gmail.com a écrit :
On Tuesday, January 6, 2015 7:38:00 PM
On Wednesday, January 7, 2015 9:36:28 PM UTC+10, Milan Bouchet-Valat wrote:
Le mardi 06 janvier 2015 à 05:27 -0800, ele...@gmail.com javascript: a
écrit :
On Tuesday, January 6, 2015 10:43:16 PM UTC+10, Milan Bouchet-Valat
wrote:
Le mardi 06 janvier 2015 à 04:38 -0800,
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
On Tuesday, January 6, 2015 10:43:16 PM UTC+10, Milan Bouchet-Valat wrote:
Le mardi 06 janvier 2015 à 04:38 -0800, ele...@gmail.com javascript: 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,
Le mardi 06 janvier 2015 à 04:38 -0800, ele...@gmail.com 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, ele...@gmail.com a écrit :
My reasoning for Nullable{T} is that it is type stable. Taking
On Tuesday, January 6, 2015 7:38:00 PM UTC+10, Milan Bouchet-Valat wrote:
Le lundi 05 janvier 2015 à 19:16 -0800, ele...@gmail.com 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,
On Tuesday, January 6, 2015 4:43:16 AM UTC-8, Milan Bouchet-Valat wrote:
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
Oops posted too soon :)
On Wednesday, January 7, 2015 10:37:01 AM UTC+10, ele...@gmail.com wrote:
[...]
This definition will be type-stable (it will always return a
Nullable{Bool}) and it will be able to signal all three possible results;
get(a) == b, get(a) != b and get(a) == null.
[...]
This definition will be type-stable (it will always return a
Nullable{Bool}) and it will be able to signal all three possible results;
get(a) == b, get(a) != b and get(a) == null.
It is then messy to use == in an if when the return is not a bool.
In fact you still have to write the
I think many of the questions raised in this thread can be answered by
considering the history behind why Nullable{T} was introduced in the first
place; to replace NAtype and NA, from the DataArrays package. As such,
Nullable{T} is supposed to be used more as Milan describes, than as a
drop-in
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}
16 matches
Mail list logo
