(Dis-) vantaggi della tipizzazione strutturale


15

Ho appena visto questo discorso di Daniel Spiewak in cui parla dei vantaggi della tipizzazione strutturale rispetto alla tipizzazione nominale di Scala e Java . Un esempio di questa differenza sarebbe il seguente codice Java

public interface Foo {
  public int length();
}
public interface Bar {
  public int length();
}

Foo f = ...;
Bar b = f;

che ovviamente non si compilerebbe perché la compatibilità dei tipi tra Fooe Barè determinata dal nome.

Un sistema di tipo strutturale d'altra parte potrebbe dichiarare entrambi i tipi uguali o compatibili e quindi, tra le altre cose, consentire la tipizzazione di anatre verificate.

Ora penso di capire la maggior parte dei vantaggi di un sistema di tipo strutturale, ma mi chiedo se non invaliderebbe la sicurezza del tipo da esempi come i seguenti

class Foo {
  class Bar { /* ... */ }
  def takeBar(b: Bar) = { /* ... */ }
  def getBar: Bar = new Bar
}

val foo1 = new Foo
val foo2 = new Foo
foo1.takeBar(foo1.getBar) // should compile
foo1.takeBar(foo2.getBar) // should not compile

La mia comprensione è corretta che in un sistema di tipo strutturale si compili anche l'ultima riga e, in tal caso, non sarebbe uno svantaggio rispetto alla sicurezza del tipo?


3
Potresti spiegare perché l'ultima riga non dovrebbe essere compilata? Non vedo l'incompatibilità del tipo.
Sam Goldberg,


In realtà, volevo discuterne dal punto di vista del sistema di tipo Scala. È appena successo che l'unico esempio fornito nel discorso era in Java.
Debilski,

Risposte:


12

In realtà, i tipi dipendenti dal percorso sono ortogonali alla tipizzazione strutturale vs nominale. Non è davvero chiaro cosa significhi una classe interiore nel contesto di un linguaggio tipicamente strutturato. È tuttavia possibile definirlo . Se dovessi definire le classi interne in un contesto strutturato strutturalmente, dovrai assicurarti che casi come quello che hai elencato vengano respinti (per gli stessi motivi per cui Scala li respinge).

Rifiuteresti questi casi facendo la stessa cosa che Scala: modella il tipo dipendente dal percorso come tipo esistenziale. La stessa procedura di pack / unpack che circonda l'accesso agli oggetti sarebbe valida e i risultati sembrerebbero quasi identici a quelli di Scala. I risultati possono sembrare un'uguaglianza di tipo nominale, ma sarebbe comunque un sistema di tipo strutturale poiché la questione della compatibilità dei tipi sarà ancora decisa sull'interfaccia piuttosto che sul nome.

La tipizzazione strutturale ha molte implicazioni, ma (forse sorprendentemente) la maggior parte degli stessi concetti che tutti conosciamo e amiamo dai sistemi di tipo nominale vengono trasferiti in strutturali. La tipizzazione strutturale non è altro che un modo diverso di definire la compatibilità dei tipi.


0

La digitazione strutturale semplifica la scrittura di codice di libreria generico. Il primo motivo per cui l'ecosistema Java è così gonfio è perché è difficile scrivere facilmente piccole librerie. Se Java fosse tipicamente strutturato penso che sarebbe una storia diversa e una situazione molto migliore.

L'unico svantaggio che mi viene in mente per la tipizzazione strutturale è il potenziale per una compilazione più lenta. Non sono sicuro che i linguaggi strutturali generalmente si compilino più lentamente di quelli nominativi o meno, ma per esempio Golang è strutturato strutturalmente e molto velocemente nella compilazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.