La logica dietro i valori di Falsy [chiuso]

Li uso a mio vantaggio in Javascript tutto il tempo. In Javascript, i valori di falsy sono undefined , null , false , NaN , 0 e ""

È molto più facile da leggere:

if( !str ) {

}

invece di

if( str == null || str.length() == 0 ) {

}

o str == null || str.equals("") o mazzetto di altri equivalenti errati che è necessario utilizzare in Java.

Ricordo un'istanza in cui sono stato morso da questo, facendo x || y , quando era desiderabile un certo valore di falsa come x . Ma questo è molto raro.

Tuttavia, il controllo è relativamente sano in Javascript. Prendi in considerazione PHP, dove in aggiunta la stringa "0" , una matrice vuota o, e cito:

SimpleXML objects created from empty tags

sono considerati valori falsi. Inoltre, NaN è vero in PHP! Quindi in questo pasticcio di incoerenza completamente arbitraria, non troverei il concetto di verità / falsità come buono.

Anche Haskell ha il concetto di falsy e io li uso sempre.

Supponiamo di avere una manciata di valori e ho bisogno di fallire se uno di questi valori è "falso" (i bool sarebbero falsi, le liste sarebbero vuote ...). Posso usare il Maybe monoid per controllare facilmente se qualcuno di questi è considerato falso in base al loro tipo.

È vero, l'istruzione "if" in Haskell consente comunque solo una condizione di test booleana, ma Haskell rende abbastanza semplice creare le proprie strutture di controllo per aggirare il problema.

La chiave è che in Haskell sono completamente controllati in modo da sapere esattamente cosa sta succedendo. Li ho desiderati in C #, ma ho fatto il giro solo cercando esplicitamente "false"

In Python è più di un concetto something rispetto a nothing , ed è incredibilmente comodo, oltre che molto più leggibile, avere le classi personalizzate impostate come nothing ( False ) se non lo fanno avere un valore significativo se usato nei test booleani.

Quasi tutte le mie classi lo supportano (molte classi di tipo contenitore).

Il problema con i valori di "falsy" è che portano inevitabilmente ad ambiguità tra le risposte dentro e fuori limite: i casi in cui un'operazione restituisce un valore "falsato" che potrebbe significare sia la mancata risposta o il successo a produrre una risposta il cui valore è il valore "falsy".

Un esempio familiare sarebbe il metodo Map<K,V>.get(K key) di Java, che restituisce null in due situazioni:

1. La mappa non ha una voce per la chiave richiesta.
2. La mappa ha una voce che associa quella chiave a null .

Contrast Haskell, dove non solo sono a e Maybe a diversi tipi, ma anche Maybe (Maybe a) e così via. In Haskell, se è necessario (e la maggior parte delle volte non lo fai), puoi distinguere tra Nothing (errore "esterno") e Just Nothing (errore "interno").

On what principles would you decide to add or exclude them from a language?

Non penso che sia la domanda giusta. Ogni progettista di linguaggi ha qualcosa in mente quando progetta la propria lingua e spesso detterà alcune delle risposte. Ad esempio, se stai progettando per la sicurezza del tipo, non permetterai che i numeri siano vere o false. Se stai progettando per "easy scripting", permetterai molte scorciatoie.

Ad esempio, SQL considera NULL e false così diversi da dover utilizzare su di essi operatori diversi ("è nullo" vs "= falso"). Ruby pensa che 0 sia vero, ma Perl pensa che sia falso.

In Ruby, l'insieme di cose false è abbastanza piccolo da essere facile da ricordare (solo falso e nullo).

Where specifically have you used them to your advantage?

Quando raccogli i valori predefiniti da varie posizioni:

my_name = env.name || command_line_swich.name || default_name
value = config['value'] || raise("no value found")

Are there any problems you could see them causing off-hand?

Sì. In Perl, fare il sopra con i numeri è una cattiva idea (perché 0 potrebbe essere valido, ma verrà ignorato perché è falso). Anche in Ruby, si interrompe quando hai valori booleani.

Are there any rules or finer points in your language/project/team about where it's appropriate or inappropriate to use them?

Non proprio. Li usiamo ovunque possiamo farla franca, il che dimostra il loro valore.