(Дис-) переваги структурного набору тексту

Я щойно спостерігав за цим розмовою Даніеля Співака, де він розповідає про переваги структурного набору тексту порівняно з номінальним типізацією Scala і Java . Одним із прикладів такої різниці може бути наступний код Java

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

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

що, звичайно, не збирається, оскільки сумісність між типом Fooі Barвизначається назвою.

Система структурного типу, з іншого боку, може оголосити обидва типи рівними або сумісними, і, крім іншого, допускати перевірене введення качок.

Тепер я думаю, що я розумію більшість переваг системи структурного типу, але мені цікаво, чи це не призведе до втрати безпеки типу на таких прикладах, як наведено нижче

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

Чи правильно я розумію, що в системі структурних типів останній рядок також буде складений, і якщо так, чи не буде це недоліком щодо безпеки типу?

Насправді типи, що залежать від шляху, є ортогональними до структурно проти номінального введення. Не зовсім зрозуміло, що означає внутрішній клас у контексті простої структурно набраної мови. Однак це дуже можливо визначити . Якби ви визначали внутрішні класи в структурно набраному контексті, вам потрібно було б переконатись, що випадки, подібні до того, який ви перераховували, будуть відхилені (саме з тих самих причин, що Скала їх відкидає).

Ви б відкидали подібні випадки, зробивши те саме, що робить Скала: моделюйте залежний від шляху тип як екзистенційний тип. Та сама процедура упаковки / розпакування, що стосується доступу до об'єктів, буде тримати, і результати виглядатимуть майже однаково, як це робить Scala. Результати можуть здатися рівності номінального типу, але все ж це буде система структурного типу, оскільки питання сумісності типів все ще вирішуватиметься не інтерфейсом, а назвою.

Структурна типізація має багато наслідків, але (можливо, дивно) більшість тих самих понять, які ми всі знаємо і любимо з систем номінального типу, переносяться на структурні. Структурне введення тексту - це не що інше, як інший спосіб визначення сумісності типів.

Структурне введення полегшує запис загального коду бібліотеки. Причина №1, чому екосистема Java настільки роздута, полягає в тому, що невеликі бібліотеки важко легко писати. Якби Java була структурно набрана, я думаю, це була б інша історія та набагато краща ситуація.

Єдиний недолік, про який я можу придумати структурну типізацію, - це потенціал уповільнення компіляції. Я не впевнений, структурні мови, як правило, збираються повільніше, ніж номінативні чи ні, але, наприклад, Golang структурно набирається та дуже швидко збирається.