Kotlin

http://confluence.jetbrains.net/display/Kotlin/Null-safety skrev:

In Kotlin the type system distinguishes between references that can hold null (nullable references) and those that can not (non-null references). For example, a regular variable of type String can not hold null:

var a : String = "abc"
a = null // compilation error

To allow nulls, one declares a variable as nullable string, written String?:

var b : String? = "abc"
b = null // ok

Now, if you call a method on a, it's guaranteed not to cause an NPE, so you can safely say

val l = a.length()

But if you want to call the same method on b, that would not be safe, and the compiler reports an error:

val l = b.length() // error: variable 'b' can be null

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Mort (7) skrev:

Hvis man fjerner null som mulig værdi, så vil udviklerne blot sætte værdierne til at pege på en anden konstant, som så får samme funktion som værdien null.

Mort (7) skrev:

Jeg foretrækker nullable data typer så jeg utvetydigt kan definere værdien som værende uinitialiseret,

Mort (7) skrev:

At mindre erfarne udviklere så har det med at glemme at initialisere variablerne og man dermed får en fejl når værdien null opstår, det må kunne løses på bedre måder end at fjerne muligheden for at sætte værdien null.

Wikipedia skrev:

In safe languages a possibly-null pointer can be replaced with a tagged union which enforces explicit handling of the exceptional case; in fact, a possibly-null pointer can be seen as a tagged pointer with a computed tag.

arne_v (8) skrev:

Sikker?

arne_v (8) skrev:

Hele pointen er vel at man vil fjerne mulighedem for unitialiserede variable.

arne_v (8) skrev:

Såsom?

type 'a list = Cons of 'a * 'a list | Empty_list

let f x = match x with
Cons a * _ -> a + 1
| Empty_list -> 0

arne_v (6) skrev:

Eksistensen af NULL/null/nil er ret omdiskuteret (i akademiske kreds).

type RelayCommand (execute : obj -> unit, canExecute : Option<obj -> bool>) =
member this.CanExecute(parameter) =
if canExecute.IsNone then
true
else
canExecute.Value(parameter)

type RelayCommand (execute : obj -> unit, canExecute : Option<obj -> bool>) =
member this.CanExecute(parameter) =
match canExecute with
| IsNone -> true
| IsSome -> canExecute.Value(parameter)

Mort (7) skrev:

Hvis man fjerner null som mulig værdi, så vil udviklerne blot sætte værdierne til at pege på en anden konstant, som så får samme funktion som værdien null.

Når value typer feks ikke kan initialiseres til null, så sætter man dem ofte i stedet til en default værdi, som feks ved tal typer ofte er tallet 0. Det betyder at værdien 0 nu kan betyde to ting: At variablen er uinitialiseret eller at variablen rent faktisk har værdien 0.

Mort (7) skrev:

Jeg foretrækker nullable data typer så jeg utvetydigt kan definere værdien som værende uinitialiseret, fremfor at skulle checke for tvetydigheden hver gang jeg bruger variablen.

Windcape (14) skrev:

Problemet er så at null ikke nødvendigvis er det samme som uinitialiseret. Det kan også være du har sat værdien til null for at indikere at den tidligere værdi skulle fjernes.

Daniel-Dane (15) skrev:

Er det ikke lige meget?

Mort (10) skrev:

Dvs du flytter blot problematikken fra at bruge null til at checke en anden variabel i stedet.

type LinkedList<'T>() =

let mutable head = Option<Node<'T>>.None

member this.Insert(value) =
let node = new Node<'T>(value);
match head with
| None -> head <- Some node
| Some(value) ->
value.Next <- Some node
head <- Some node

head.Next <- node

open System

type Node<'T>(nodeValue : 'T, next : Node<'T> option) =

member this.NodeValue
with get() =
nodeValue

member this.Next
with get() =
next

type LinkedList<'T>() =

let mutable head = Option<Node<'T>>.None

let rec printList (node : Node<'T> option) =
match node with
| None -> None
| Some(value) ->
printfn "%A" value.NodeValue
match value.Next with
| None -> None
| Some(nextNode) -> printList(Some nextNode)

member this.Insert(value) =
let nextNode = new Node<'T>(value, head)
head <- Some nextNode

member this.PrintList() =
printList(head)

let list = new LinkedList<string>()
list.Insert("foo")
list.Insert("bar")
list.Insert("bas")
list.PrintList() |> ignore

Console.Read() |> ignore

tazimn (2) skrev:

Som jeg læser det, giver de, ikke-nullable variabler, ikke længere en NullPointerException, men fejler bare i stilhed.. Dvs at det nu bliver sværere for udviklere at finde fejl!

var xml = GetXmlFromRemoteService();
var document = XElement.Parse(xml)
var rootElement = document.Element("foo")
var barElements = rootElement.Elements("bar")

let xml = GetXmlFromRemoteService();
let document = XElement.Parse(xml)
let rootElement = document.Element("foo")
match rootElement with
| None ->
MessageBox.Show("An error occoured retriving the data. Please try again later");
| Some(value) ->
let barElements = value.Elements("bar")

Windcape (19) skrev:

Problemet er jo, når at du f.eks. henter data fra en 3rd parts service. Eksemple:

var xml = GetXmlFromRemoteService();
var document = XElement.Parse(xml)
var rootElement = document.Element("foo")
var barElements = rootElement.Elements("bar")

Så forestiller vi os lige at vores 3rd parts service fejler, og der pludselig ikke er noget "foo" element. Altså er "rootElement" variablen null, og vi får en NPE. Træls! Fordi nu crasher din app, og det vil tage dig mindst 2 dage at deploy et fix.

var xml = GetXmlFromRemoteService();
var document = XElement.Parse(xml)
var rootElement = "";
if (document.Element("foo")){
rootElement = document.Element("foo")
}
var barElements = rootElement.Elements("bar")

Windcape (16) skrev:

Ikke nødvendigvis. I det ene tilfælde er dit reference objekt null (som default værdi), i det andet bruger du specifikt null som en faktisk værdi.

Hvilket er forkert! Her er en option bedre.

onetreehell (23) skrev:

Hvorfor er der så mange paranteser i dit F# kode?

onetreehell (23) skrev:

Edit: also hvorfor har du ingen projekter? :(

Daniel-Dane (24) skrev:

Hvis #21 havde checket eksplicit mod null (ala foo===null), ville det da være det samme som None.

var
obj: TObj // dynamisk objekt
begin
//obj := TObj.Create;
obj.DoStuff();
end

Windcape (28) skrev:

(Hvor der netop er 2 dages deployment tid, hvilket gør NPEs super irreterende)

                match value.Next with
| None -> None
| Some nextNode -> printList (Some nextNode)

member this.Insert value =
let nextNode = new Node<'T>(value, head)
head <- Some nextNode

list.Insert "foo"
list.Insert "bar"
list.Insert "bas"

onetreehell (31) skrev:

Er al din F# kode så mutable?

Windcape (28) skrev:

Eksemplet jeg gav med XElement tidligere var et rigtigt eksempel, fra en fejl i en af mine mobile apps.

Daniel-Dane (33) skrev:

F# er fandeme hieroglyffer.

Daniel-Dane (33) skrev:

En anden årsag til, at jeg ikke får de problemer er, at jeg ikke programmerer.

Windcape (34) skrev:

hah :D Godt jeg ikke valgte haskell som eksempel sprog så!

let add3 x y z = x + y + z

Daniel-Dane (33) skrev:

Jeg kan ikke læse F# (*), men det ser meget pænt ud (bortset fra at man skal gentage meget kode). Jeg synes stadig (i din kode), at du checker mod None hele tiden (som lige så godt kunne være null).

Nå, drop det, Windcape. Jeg checker altid mod null (i hvert fald objekter og funktioner, jeg ikke kender), så jeg får ikke de problemer alligevel (**).

Daniel-Dane (33) skrev:

Jeg stødte på en fuld datalog en nat, som fortalte, at man som datalog ikke lærer programmeringssprog men programmering. Resten var bare semantik eller sådan noget.

Mort (10) skrev:

Konkret eksempel: Lav en linked list uden brug af en uinitialiserings indikator som feks null eller predefineret værdi. Du kan godt gøre det, men det kræver at du bruger en anden værdi til at indikere at et element i listen er det sidste element - Dvs du flytter blot problematikken fra at bruge null til at checke en anden variabel i stedet.

Mort (10) skrev:

Du kan feks kræve at alle variable eksplicit får erklæret en værdi, når de defineres.

Windcape (12) skrev:

heh, de har stjålet C#s syntax for nullable types.

Windcape (13) skrev:

Alternativet, som f.eks. F# har, er at bruge Options.

Windcape (14) skrev:

Igen, i F# ville du bruge en Option, og sætte værdien til "None". Men til modsætning fra Null, så er None et slags flag, og ikke en værdi.

Windcape (18) skrev:

100% frit for null !

Windcape (19) skrev:

Meget mere sikker kode! Og til modsætning fra det første eksempel, kan du ikke "glemme" at håndtere None/Some, til modsætning fra null.

Windcape (26) skrev:

Men forskellen er bare stadigvæk at du ikke kan lave:

<null>.DoStuff() med options.
<option>.DoStuff() vil ikke compile.

#light
let s2 : string option = None;;
printfn "%s" (s2.ToString());;

let s : string option = None
print_string s

let s = Some "Hello, World!"
print_string s

onetreehell (42) skrev:

Umiddelbart tror jeg ikke du kan det der og vil få en compile fejl.

arne_v (45) skrev:

Jeg gætter på at det er en form for side effect af at F# skal passe ind i .NET konteksten.

match s2 with
| None -> None
| Some s2 -> printf "%s" s2

match s2 with
| null -> noop
| Some s2 -> printf "%s" s

class N
{
private string name; // equiv to setting the value to = null.
}

Windcape (46) skrev:

Det er en F# optimization. En null option er bogstaveligtalt null.

Men det er meningen at man altid skal bruge options med match.

dvs.

match s2 with
| None -> None
| Some s2 -> printf "%s" s2