Testowanie zerowy odniesienia w F #

Question

Biorąc pod uwagę następujące elementy:

[<DataContract>] 
type TweetUser = { 
    [<field:DataMember(Name="followers_count")>] Followers:int 
    [<field:DataMember(Name="screen_name")>] Name:string 
    [<field:DataMember(Name="id_str")>] Id:int 
    [<field:DataMember(Name="location")>] Location:string} 

[<DataContract>] 
type Tweet = { 
    [<field:DataMember(Name="id_str")>] Id:string 
    [<field:DataMember(Name="text")>] Text:string 
    [<field:DataMember(Name="retweeted")>] IsRetweeted:bool 
    [<field:DataMember(Name="created_at")>] DateStr:string 
    [<field:DataMember(Name="user", IsRequired=false)>] User:TweetUser 
    [<field:DataMember(Name="sender", IsRequired=false)>] Sender:TweetUser 
    [<field:DataMember(Name="source")>] Source:string} 

deserializacji z DataContractJsonSerializer(typeof<Tweet[]>) spowoduje użytkownika albo polu nadawcy jest zerowa (przynajmniej to co debugger mówi mi).

Gdy próbuję napisać następujące:

let name = if tweet.User <> null 
        then tweet.User.Name 
        else tweet.Sender.Name 

kompilator emituje ten błąd: „Typ«TweetUser»nie ma«null»jako właściwą wartość”

Jak przetestować wartości null w tym przypadku?

Answer 1

Aby cyklicznie rozwinąć odpowiedź @Tomas; -]

let name = if not <| obj.ReferenceEquals (tweet.User, null) 
       then tweet.User.Name 
       else tweet.Sender.Name 

lub

let inline isNull (x:^T when ^T : not struct) = obj.ReferenceEquals (x, null) 

Unchecked.defaultof<_> robi słusznie i produkcji null dla swoich typów rekordów; Problem polega na tym, że domyślny operator równości używa generycznego porównania strukturalnego, które oczekuje, że zawsze będziesz grał według reguł F #, gdy używasz typów F #. W każdym razie kontrola zerowa rzeczywiście tylko gwarantuje porównanie referencyjne w pierwszej kolejności.

Answer 2

Aby dodać niektóre szczegóły do ​​komentarza przez @ildjarn, otrzymujesz komunikat o błędzie, ponieważ F # nie zezwala na używanie null jako wartości typów zadeklarowanych w F #. Motywacją tego jest fakt, że F # próbuje wyeliminować wartości (i NullReferenceException) z czystych programów F #.

Jednakże, jeśli używasz typów, które nie są zdefiniowane w F #, nadal mogą korzystać null (np podczas wywoływania funkcji, która pobiera System.Random jako argument można podać go null). Jest to potrzebne do zapewnienia interoperacyjności, ponieważ może być konieczne przekazanie null do biblioteki .NET lub zaakceptowanie jej jako wynik.

W przykładzie TweetUser jest (zapis) Typ zadeklarowane w F #, więc język nie pozwala na traktowanie null jako wartość typu TweetUser. Jednak nadal można uzyskać wartość null za pośrednictwem Reflection lub z kodu C#, więc F # zapewnia "niebezpieczną" funkcję, która tworzy wartość dowolnego typu - włącznie z rekordami F #, które normalnie nie powinny mieć wartości null. Jest to funkcja Unchecked.defaultOf<_> i można go używać do wdrożenia pomocnika takiego:

let inline isNull x = x = Unchecked.defaultof<_> 

Ewentualnie, jeśli oznaczyć typu z atrybutem AllowNullLiteral, a potem mówisz do F # kompilator, że powinien on umożliwić null jako wartość dla tego konkretnego typu, nawet jeśli jest to typ zadeklarowany w F # (i normalnie nie pozwoliłby na to null).

Answer 3

Chociaż to pytanie jest stare, nie widziałem żadnych przykładów boksu, aby rozwiązać problem. W przypadkach, w których mój prezenter nie dopuszcza literałów zerowych, ale może być ustawiony z widoku, wolę używać boksu.

isNull <| box obj 

lub

let isMyObjNull = isNull <| box obj 

lub

match box obj with 
| isNull -> (* obj is null *) 
| _ -> (* obj is not null *)