È possibile avere una lingua digitata dinamicamente senza digitazione anatra? [chiuso]

Innanzitutto, per assicurarci che stiamo parlando delle stesse cose, vorrei iniziare con alcune definizioni.

La tipizzazione statica significa che gli errori di tipo sono riportati in fase di compilazione, mentre la digitazione dinamica significa che gli errori di tipo sono riportati in fase di esecuzione.

Duck typing significa che una parte di codice richiede che un oggetto supporti le operazioni che vengono utilizzate e nient'altro.

La tipizzazione strutturale richiede che un oggetto supporti un determinato insieme di operazioni (anche se alcune di esse non possono essere utilizzate).

La tipizzazione nominale richiede che l'oggetto sia esattamente del tipo specificato o che sia un sottotipo di quel tipo.

Quindi, come puoi vedere, la tipizzazione strutturale è più severa della digitazione anatra e la digitazione nominale è più rigida di quella strutturale.

Ora parlerò di il linguaggio TypeScript , perché illustra bene la maggior parte di queste opzioni.

Considera il seguente programma TypeScript:

interface Person {
    Name : string;
    Age : number;
}

function greet(person : Person) {
    alert("Hello, " + person.Name);
}

greet({ Name: "svick" });

Poiché l'oggetto passato a greet non ha la proprietà Age , ciò causa un errore in fase di compilazione, a dimostrazione che TypeScript utilizza tipizzazione strutturale statica .

Nonostante l'errore, il codice sopra in realtà viene compilato sul seguente JavaScript, che funziona perfettamente:

function greet(person) {
    alert("Hello, " + person.Name);
}

greet({ Name: "svick" });

Questo dimostra che TypeScript usa anche typing anatra dinamico .

Se il codice invece è compilato in modo simile a:

function greet(person) {
    if (!(typeof(person.Name) == 'string' && typeof(person.Age) == 'number'))
        throw 'TypeError';

    alert("Hello, " + person.Name);
}

Quindi questo sarebbe un esempio di tipizzazione strutturale dinamica , perché controlla che l'oggetto abbia le proprietà richieste dei tipi richiesti, anche se la funzione stessa non li richiede.

Se è compilato per:

function greet(person) {
    if (!(person instanceof Person))
        throw 'TypeError'

    alert("Hello, " + person.Name);
}

Sarebbe un esempio di tipizzazione nominale dinamica , perché controlla il nome del tipo dell'oggetto, non la sua struttura.

Ciò che questo dimostra è che la digitazione dinamica senza anatra è possibile (sia strutturale che nominale). Ma questo approccio non viene usato molto spesso, perché combina principalmente gli svantaggi della digitazione non anatra (devi specificare i tipi in modo esplicito, meno flessibile) e la digitazione dinamica (gli errori di tipo vengono visualizzati solo in fase di esecuzione e solo nel codice che viene effettivamente eseguito) ).

Se vuoi aggiungere annotazioni di tipo per rendere possibile la digitazione non anatra, puoi anche controllare i tipi in fase di compilazione.

Apparentemente (da ciò che ho letto) Duck typing ha significato solo in un contesto orientato agli oggetti, quando le funzioni sono collegate come metodi a oggetti. Quindi quando scrivi duck.quacks(3) , questo funzionerà se il il valore corrente di duck ha il metodo quacks .

La digitazione dinamica non è necessariamente associata a una vista OO con metodi.

È possibile definire il tipo real con l'operatore o la funzione associati +: real*real->real e il tipo rational con l'associato operatore +: rational*rational->rational . Quindi se scrivi a+b , in un sistema di tempo a controllo dinamico, sia le variabili a che b possono avere un operatore + , ma si ottiene un errore di tipo run-time.

Controlli di digitazione dinamica per coerenza dei valori categoriale, possibilmente molti di loro.

La tipizzazione degli anatra verifica la coerenza comportamentale del codice con un oggetto a portata di mano (uno solo, per quanto ho capito).

In un certo senso, la digitazione anatra è una forma di polimorfismo di runtime, ad eccezione di il fatto che si applica solo ai metodi di accesso di un singolo oggetto.

Tuttavia, è possibile definire una forma più generica di runtime polimorfismo, dove dovrebbe essere l'operatore + da eseguire determinato sulla base di tutti gli argomenti. In modo che un'anatra e un pollo potrebbe ballare insieme se condividono una funzione danse comune. Potevano avere diversi in modo che le anatre possano ballare anche con oche con un diverso funzione. Ma sembra un po 'complicato. Per quanto mi ricordo, qualcosa del genere (probabilmente con più struttura) potrebbe essere stato possibile con le funzioni generiche del lingua EL1 , molto vecchio precursore di linguaggi orientati agli oggetti.

Una risposta per analogia:

Puoi acquistare una deccapottabile e non metterla mai giù? Sicuro. Probabilmente non è il modo migliore per spendere le tue risorse, dal momento che sei pagato extra per alcune caratteristiche (es. Capote, irrigidimento strutturale supplementare dovuto alla mancanza di tetto come elemento strutturale) e ottenuto risultati peggiori (ad esempio rumore stradale aggiuntivo, forse inferiore sicurezza in caso di incidente, compartimenti di stoccaggio più piccoli) a seguito dell'investimento in quella funzione che non utilizzerai. Ma è tecnicamente fattibile.

È lo stesso con le lingue dinamiche e la digitazione anatra. Hai rinunciato all'efficacia più elevata e alle garanzie di sicurezza del tipo in fase di compilazione dei linguaggi statici. Per cosa? Generalmente per la semplicità della digitazione anatra. Variabili e collezioni possono contenere qualsiasi cosa, e non è necessario fare molto in anticipo specificando cosa. Le raccolte miste come [ 12, "gumbo", 12.4, 4+4j ] (un intero, una stringa, un valore in virgola mobile e un valore complesso) sono banali e non si ha il tipo costante di casting che si vede nel codice Java (ad esempio).

È possibile in un linguaggio dinamico come Python creare oggetti che non siano digitati a macchina:

class Hungarian(object):
    self __init__(self):
        self.value = []
    self addInt(self, intValue):
        self.value.append(intValue)
    self addFloat(self, floatValue):
        self.value.append(floatValue)
    self addComplex(self, complexValue):
        self.value.append(complexValue)
    # ...

Ma come potresti notare, non esiste un vero controllo dei tipi, e ciascuno dei metodi è implementato con una struttura incorporata anatra ( list ). Avendo pagato il prezzo per il dinamismo, si potrebbe anche mettere il top-down e ottenere la semplicità risultante:

class NotHungarian(object):
    def __init__(self):
        self.value = []
    def add(self, whatever):
        self.value.append(whatever)