È una cattiva idea restituire tipi di dati diversi da una singola funzione in un linguaggio tipizzato in modo dinamico?

La mia lingua principale è di tipo statico (Java). In Java, è necessario restituire un singolo tipo da ogni metodo. Ad esempio, non è possibile avere un metodo che restituisce un condizionatamente Stringo ritorna condizionalmente una Integer. Ma in JavaScript, ad esempio, questo è molto possibile.

In un linguaggio tipicamente statico capisco perché questa è una cattiva idea. Se ogni metodo restituito Object(il genitore comune da cui ereditano tutte le classi), tu e il compilatore non avete idea di cosa avete a che fare. Dovrai scoprire tutti i tuoi errori in fase di esecuzione.

Ma in un linguaggio tipizzato in modo dinamico, potrebbe non esserci nemmeno un compilatore. In un linguaggio tipizzato in modo dinamico, non è ovvio per me una funzione che restituisce più tipi è una cattiva idea. Il mio background in linguaggi statici mi evita di scrivere tali funzioni, ma temo di avere una mentalità molto attenta a una funzionalità che potrebbe rendere il mio codice più pulito in modi che non riesco a vedere.

Modifica : ho intenzione di rimuovere il mio esempio (fino a quando non riesco a pensare a uno migliore). Penso che stia guidando le persone a rispondere a un punto che non sto cercando di esprimere.

Al contrario di altre risposte, ci sono casi in cui è accettabile la restituzione di tipi diversi.

Esempio 1

sum(2, 3) → int
sum(2.1, 3.7) → float

In alcuni linguaggi tipicamente statici, ciò comporta sovraccarichi, quindi possiamo considerare che esistono diversi metodi, ognuno dei quali restituisce il tipo predefinito predefinito. Nei linguaggi dinamici, questa può essere la stessa funzione, implementata come:

var sum = function (a, b) {
    return a + b;
};

Stessa funzione, diversi tipi di valore restituito.

Esempio 2

Immagina di ottenere una risposta da un componente OpenID / OAuth. Alcuni provider OpenID / OAuth possono contenere più informazioni, come l'età della persona.

var user = authProvider.findCurrent();
// user is now:
// {
//     provider: 'Facebook',
//     name: {
//         firstName: 'Hello',
//         secondName: 'World',
//     },
//     email: 'hello.world@example.com',
//     age: 27
// }

Altri avrebbero il minimo, sarebbe un indirizzo e-mail o lo pseudonimo.

var user = authProvider.findCurrent();
// user is now:
// {
//     provider: 'Google',
//     email: 'hello.world@example.com'
// }

Ancora una volta, stessa funzione, risultati diversi.

Qui, il vantaggio di restituire tipi diversi è particolarmente importante in un contesto in cui non ti interessano i tipi e le interfacce, ma quali oggetti contengano effettivamente. Ad esempio, immaginiamo che un sito Web contenga un linguaggio maturo. Quindi findCurrent()può essere usato in questo modo:

var user = authProvider.findCurrent();
if (user.age || 0 >= 16) {
    // The person can stand mature language.
    allowShowingContent();
} else if (user.age) {
    // OpenID/OAuth gave the age, but the person appears too young to see the content.
    showParentalAdvisoryRequestedMessage();
} else {
    // OpenID/OAuth won't tell the age of the person. Ask the user himself.
    askForAge();
}

Rifattorizzare questo in codice in cui ogni provider avrà la propria funzione che restituirà un tipo fisso ben definito non solo degraderebbe la base di codice e causerebbe la duplicazione del codice, ma non apporterebbe alcun vantaggio. Si potrebbe finire per fare orrori come:

var age;
if (['Facebook', 'Yahoo', 'Blogger', 'LiveJournal'].contains(user.provider)) {
    age = user.age;
}

In generale, è una cattiva idea per le stesse ragioni per cui l'equivalente morale in un linguaggio tipicamente statico è una cattiva idea: non hai idea di quale tipo concreto venga restituito, quindi non hai idea di cosa puoi fare con il risultato (a parte il poche cose che possono essere fatte con qualsiasi valore). In un sistema di tipi statici, hai annotazioni verificate dal compilatore dei tipi restituiti e simili, ma in un linguaggio dinamico esiste ancora la stessa conoscenza: è solo informale e memorizzata nel cervello e nella documentazione piuttosto che nel codice sorgente.

In molti casi, tuttavia, esiste una rima e una ragione per cui viene restituito il tipo e l'effetto è simile al sovraccarico o al polimorfismo parametrico nei sistemi di tipo statico. In altre parole, il tipo di risultato è prevedibile, non è altrettanto semplice da esprimere.

Si noti tuttavia che potrebbero esserci altri motivi per cui una funzione specifica è progettata in modo sumerrato : ad esempio, una funzione che restituisce false su input non validi è una cattiva idea principalmente perché quel valore di ritorno è inutile e soggetto a errori (0 <-> false confusion).

Nei linguaggi dinamici, non dovresti chiedere se restituiscono tipi diversi ma oggetti con API diverse . Dato che la maggior parte dei linguaggi dinamici non si preoccupa davvero dei tipi, ma usa varie versioni della tipizzazione duck .

Quando si restituiscono tipi diversi ha senso

Ad esempio questo metodo ha senso:

def load_file(file): 
    if something: 
       return ['a ', 'list', 'of', 'strings'] 
    return open(file, 'r')

Perché sia ​​il file che un elenco di stringhe sono (in Python) iterabili che restituiscono stringa. Tipi molto diversi, la stessa API (a meno che qualcuno non provi a chiamare metodi di file in un elenco, ma questa è una storia diversa).

È possibile restituire in modo condizionale listo tuple( tupleè un elenco immutabile in Python).

Formalmente anche facendo:

def do_something():
    if ...: 
        return None
    return something_else

o:

function do_something(){
   if (...) return null; 
   return sth;
}

restituisce tipi diversi, poiché sia ​​python Noneche Javascript nullsono tipi a sé stanti.

Tutti questi casi d'uso avrebbero la loro controparte in linguaggi statici, la funzione restituirebbe semplicemente un'interfaccia corretta.

Quando si restituiscono oggetti con diverse API in modo condizionale è una buona idea

Se la restituzione di API diverse sia una buona idea, nella maggior parte dei casi l'IMO non ha senso. L'unico esempio sensato che viene in mente è qualcosa di simile a quello che ha detto @MainMa : quando la tua API può fornire una quantità variabile di dettagli, potrebbe avere senso restituire ulteriori dettagli quando disponibili.

La tua domanda mi fa venir voglia di piangere un po '. Non per l'uso esemplificativo che hai fornito, ma perché qualcuno involontariamente porterà troppo lontano questo approccio. È a un passo dal codice ridicolmente non mantenibile.

La condizione di errore usa il tipo di caso di senso, e il modello null (tutto deve essere un modello) in linguaggi tipicamente statici fa lo stesso tipo di cose. La chiamata di funzione restituisce objecto oppure ritorna null.

Ma è un breve passo a dire "ho intenzione di usare questo per creare un modello di fabbrica " e tornare sia fooo baroppure baza seconda dell'umore della funzione. Il debug diventerà un incubo quando il chiamante si aspetta fooma è stato dato bar.

Quindi non penso che tu sia di mentalità chiusa. Sei stato adeguatamente cauto su come usare le funzionalità del linguaggio.

Divulgazione: il mio background è in linguaggi tipicamente statici e in genere ho lavorato su team più grandi e diversificati in cui la necessità di codice gestibile era piuttosto elevata. Quindi anche la mia prospettiva è probabilmente distorta.

L'uso di Generics in Java consente di restituire un tipo diverso, pur mantenendo la sicurezza del tipo statico. È sufficiente specificare il tipo che si desidera restituire nel parametro di tipo generico della chiamata di funzione.

Se sia possibile utilizzare un approccio simile in Javascript è, ovviamente, una domanda aperta. Poiché Javascript è un linguaggio tipizzato in modo dinamico, restituire una objectsembra la scelta più ovvia.

Se vuoi sapere dove potrebbe funzionare uno scenario di ritorno dinamico quando sei abituato a lavorare in un linguaggio tipicamente statico, considera la dynamicparola chiave in C #. Rob Conery è stato in grado di scrivere con successo un mappatore relazionale di oggetti in 400 righe di codice usando la dynamicparola chiave.

Ovviamente, tutto ciò dynamicche fa è avvolgere una objectvariabile con una certa sicurezza di tipo runtime.

È una cattiva idea, penso, di restituire condizionalmente diversi tipi. Uno dei modi in cui questo si presenta frequentemente per me è se la funzione può restituire uno o più valori. Se è necessario restituire un solo valore, può sembrare ragionevole restituire il valore, anziché impacchettarlo in un array, per evitare di doverlo decomprimere nella funzione chiamante. Tuttavia, questo (e la maggior parte degli altri casi) impone al chiamante di distinguere e gestire entrambi i tipi. La funzione sarà più facile da ragionare se restituisce sempre lo stesso tipo.

La "cattiva pratica" esiste indipendentemente dal fatto che la tua lingua sia tipizzata staticamente. Il linguaggio statico fa di più per allontanarti da queste pratiche e potresti trovare più utenti che si lamentano di "cattive pratiche" in un linguaggio statico perché è un linguaggio più formale. Tuttavia, i problemi sottostanti sono presenti in un linguaggio dinamico e puoi determinare se sono giustificati.

Ecco la parte discutibile di ciò che proponi. Se non so quale tipo viene restituito, non posso utilizzare immediatamente il valore restituito. Devo "scoprire" qualcosa al riguardo.

total = sum_of_array([20, 30, 'q', 50])
if (type_of(total) == Boolean) {
  display_error(...)
} else {
  record_number(total)
}

Spesso questo tipo di commutazione nel codice è semplicemente una cattiva pratica. Rende il codice più difficile da leggere. In questo esempio, vedi perché è popolare lanciare e catturare casi eccezionali. In altre parole: se la tua funzione non può fare ciò che dice di fare, non dovrebbe tornare correttamente . Se chiamo la tua funzione, voglio fare questo:

total = sum_of_array([20, 30, 'q', 50])
display_number(total)

Poiché la prima riga restituisce correttamente, suppongo che totalcontenga effettivamente la somma dell'array. Se non ritorna con successo, passiamo a un'altra pagina del mio programma.

Usiamo un altro esempio che non riguarda solo la propagazione degli errori. Forse sum_of_array cerca di essere intelligente e restituire una stringa leggibile dall'uomo in alcuni casi, come "Questa è la mia combinazione di armadietti!" se e solo se l'array è [11,7,19]. Ho problemi a pensare a un buon esempio. Ad ogni modo, si applica lo stesso problema. Devi ispezionare il valore restituito prima di poter fare qualsiasi cosa con esso:

total = sum_of_array([20, 30, 40, 50])
if (type_of(total) == String) {
  write_message(total)
} else {
  record_number(total)
}

Si potrebbe sostenere che sarebbe utile che la funzione restituisca un numero intero o un float, ad esempio:

sum_of_array(20, 30, 40) -> int
sum_of_array(23.45, 45.67, 67.789044) -> float

Ma quei risultati non sono di tipo diverso, per quanto ti riguarda. Li tratterai entrambi come numeri, ed è tutto ciò che ti interessa. Quindi sum_of_array restituisce il tipo di numero. Questo è il polimorfismo.

Quindi ci sono alcune pratiche che potresti violare se la tua funzione può restituire più tipi. Conoscerli ti aiuterà a determinare se la tua particolare funzione deve comunque restituire più tipi.

In realtà, non è affatto raro restituire tipi diversi anche in una lingua tipizzata staticamente. Ecco perché abbiamo tipi di unione, per esempio.

In effetti, i metodi in Java restituiscono quasi sempre uno dei quattro tipi: un tipo di oggetto o nullun'eccezione o non ritornano mai affatto.

In molte lingue, le condizioni di errore sono modellate come subroutine che restituiscono un tipo di risultato o un tipo di errore. Ad esempio, in Scala:

def transferMoney(amount: Decimal): Either[String, Decimal]

Questo è un esempio stupido, ovviamente. Il tipo restituito significa "restituisce una stringa o un decimale". Per convenzione, il tipo sinistro è il tipo di errore (in questo caso, una stringa con il messaggio di errore) e il tipo giusto è il tipo di risultato.

Ciò è simile alle eccezioni, ad eccezione del fatto che le eccezioni sono anche costrutti di flusso di controllo. Sono, infatti, equivalenti in potenza espressiva a GOTO.

Nessuna risposta ha ancora menzionato i principi SOLID. In particolare, dovresti seguire il principio di sostituzione di Liskov, secondo cui qualsiasi classe che riceve un tipo diverso dal tipo previsto può comunque funzionare con qualunque cosa ottenga, senza fare nulla per testare quale tipo viene restituito.

Quindi, se si gettano alcune proprietà extra su un oggetto o si avvolge una funzione restituita con un qualche tipo di decoratore che realizza ancora ciò che la funzione originale doveva realizzare, sei buono, a condizione che nessun codice che chiama la tua funzione si basi mai su questo comportamento, in qualsiasi percorso di codice.

Invece di restituire una stringa o un numero intero, un esempio migliore potrebbe essere che restituisce un sistema di irrigazione o un gatto. Questo va bene se tutto il codice chiamante sta per fare è chiamare functionInQuestion.hiss (). In effetti hai un'interfaccia implicita che il codice chiamante si aspetta e un linguaggio tipizzato in modo dinamico non ti costringerà a rendere esplicita l'interfaccia.

Sfortunatamente, i tuoi colleghi probabilmente lo faranno, quindi probabilmente dovrai fare lo stesso lavoro nella tua documentazione, tranne per il fatto che non esiste un modo universalmente accettato, conciso e analizzabile dalla macchina per farlo - come accade quando si definisce un'interfaccia in una lingua che li ha.

L'unico posto in cui mi vedo inviare tipi diversi è per input non validi o "eccezioni per poveri" in cui la condizione "eccezionale" non è molto eccezionale. Ad esempio, dal mio repository di funzioni di utilità PHP questo esempio abbreviato:

function ensure_fields($consideration)
{
        $args = func_get_args();
        foreach ( $args as $a ) {
                if ( !is_string($a) ) {
                        return NULL;
                }
                if ( !isset($consideration[$a]) || $consideration[$a]=='' ) {
                        return FALSE;
                }
        }

        return TRUE;
}

La funzione restituisce nominalmente un BOOLEANO, tuttavia restituisce NULL su input non valido. Si noti che da PHP 5.3, tutte le funzioni PHP interne si comportano in questo modo . Inoltre, alcune funzioni PHP interne restituiscono FALSE o INT sull'ingresso nominale, vedere:

strpos('Hello', 'e');  // Returns INT(1)
strpos('Hello', 'q');  // Returns BOOL(FALSE)

Non penso sia una cattiva idea! Contrariamente a questa opinione più comune, e come già sottolineato da Robert Harvey, linguaggi tipicamente statici come Java hanno introdotto Generics esattamente per situazioni come quella che si sta chiedendo. In realtà Java cerca di mantenere (ove possibile) la sicurezza dei caratteri al momento della compilazione, e talvolta i generici evitano la duplicazione del codice, perché? Perché è possibile scrivere lo stesso metodo o la stessa classe che gestisce / restituisce tipi diversi . Farò solo un brevissimo esempio per mostrare questa idea:

Java 1.4

public static Boolean getBoolean(String property){
    return (Boolean) properties.getProperty(property);
}
public static Integer getInt(String property){
    return (Integer) properties.getProperty(property);
}

Java 1.5+

public static <T> getValue(String property, Class<T> clazz) throws WhateverCheckedException{
    return clazz.getConstructor(String.class).newInstance(properties.getProperty(property));
}
//the call will be
Boolean b = getValue("useProxy",Boolean.class);
Integer b = getValue("proxyPort",Integer.class);

In un linguaggio tipizzato dinamico, poiché al momento della compilazione non hai alcuna sicurezza di battitura, sei assolutamente libero di scrivere lo stesso codice che funziona per molti tipi. Poiché anche in un linguaggio tipicamente statico sono stati introdotti i generici per risolvere questo problema, è chiaramente un indizio che scrivere una funzione che restituisce tipi diversi in un linguaggio dinamico non sia una cattiva idea.

Lo sviluppo di software è fondamentalmente un'arte e un mestiere di gestione della complessità. Cerchi di restringere il sistema nei punti che ti puoi permettere e limitare le opzioni in altri punti. L'interfaccia di Function è un contratto che aiuta a gestire la complessità del codice limitando una conoscenza necessaria per lavorare con qualsiasi pezzo di codice. Restituendo diversi tipi si espande significativamente l'interfaccia della funzione aggiungendo ad essa tutte le interfacce di diversi tipi restituiti E aggiungendo regole non visibili su quale interfaccia viene restituita.

Perl lo usa molto perché ciò che una funzione fa dipende dal suo contesto . Ad esempio, una funzione potrebbe restituire una matrice se utilizzata nel contesto dell'elenco o la lunghezza della matrice se utilizzata in un luogo in cui è previsto un valore scalare. Dal tutorial che è il primo successo per "contesto perl" , se lo fai:

my @now = localtime();

Quindi @now è una variabile di matrice (ecco cosa significa @) e conterrà una matrice come (40, 51, 20, 9, 0, 109, 5, 8, 0).

Se invece chiamate la funzione in un modo in cui il suo risultato dovrà essere uno scalare, con ($ le variabili sono scalari):

my $now = localtime();

poi fa qualcosa di completamente diverso: $ ora sarà qualcosa del tipo "Ven 9 gennaio 20:51:40 2009".

Un altro esempio che mi viene in mente è l'implementazione delle API REST, in cui il formato di ciò che viene restituito dipende da ciò che il cliente desidera. Ad esempio, HTML o JSON o XML. Sebbene tecnicamente quelli siano tutti flussi di byte, l'idea è simile.

Nella terra dinamica è tutta una questione di dattilografia. La cosa più responsabile esposta / rivolta al pubblico è quella di avvolgere tipi potenzialmente diversi in un wrapper che dia loro la stessa interfaccia.

function ThingyWrapper(thingy){ //a function constructor (class-like thingy)

    //thingy is effectively private and persistent for ThingyWrapper instances

    if(typeof thingy === 'array'){
        this.alertItems = function(){
            thingy.forEach(function(el){ alert(el); });
        }
    }
    else {
        this.alertItems = function(){
            for(var x in thingy){ alert(thingy[x]); }
        }
    }
}

function gimmeThingy(){
    var
        coinToss = Math.round( Math.random() ),//gives me 0 or 1
        arrayThingy = [1,2,3],
        objectThingy = { item1:1, item2:2, item3:3 }
    ;

    //0 dynamically evaluates to false in JS
    return new ThingyWrapper( coinToss ? arrayThingy : objectThingy );
}

gimmeThingy().alertItems(); //should be same every time except order of numbers - maybe

Occasionalmente potrebbe avere senso estrarre del tutto diversi tipi senza un wrapper generico ma onestamente negli anni 7ish di scrittura di JS, non è qualcosa che ho trovato ragionevole o conveniente fare molto spesso. Per lo più è qualcosa che farei nel contesto di ambienti chiusi come l'interno di un oggetto in cui le cose vengono messe insieme. Ma non è qualcosa che ho fatto abbastanza spesso che mi venga in mente qualche esempio.

Principalmente, consiglierei di smettere di pensare ai tipi del tutto. Ti occupi di tipi quando è necessario in un linguaggio dinamico. Non piu. È il punto. Non controllare il tipo di ogni singolo argomento. È qualcosa che sarei tentato di fare solo in un ambiente in cui lo stesso metodo potrebbe dare risultati incoerenti in modi non visibili (quindi sicuramente non fare qualcosa del genere). Ma non è il tipo che conta, è come funziona qualunque cosa tu mi dia.