(Dis-) keuntungan dari pengetikan struktural

15

Saya baru saja menyaksikan pembicaraan oleh Daniel Spiewak ini di mana ia berbicara tentang keuntungan pengetikan struktural dibandingkan dengan pengetikan nominal Jawa Scala dan Jawa . Salah satu contoh untuk perbedaan ini adalah kode Java berikut

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

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

yang tentu saja tidak akan dikompilasi karena jenis kompatibilitas antara Foodan Barditentukan oleh nama.

Sistem tipe struktural di sisi lain dapat menyatakan kedua jenis tersebut sama atau kompatibel dan dengan demikian, di antara hal-hal lainnya, memungkinkan untuk mengetik bebek yang diperiksa.

Sekarang saya pikir saya mengerti sebagian besar keuntungan dari sistem tipe struktural tapi saya bertanya-tanya apakah itu tidak akan membatalkan keselamatan tipe dari contoh-contoh seperti berikut ini

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

Apakah pemahaman saya benar bahwa dalam sistem tipe struktural, baris terakhir akan dikompilasi juga dan jika demikian, bukankah ini akan menjadi kerugian sehubungan dengan keamanan jenis?

— Debilski
sumber

3

Bisakah Anda menjelaskan mengapa baris terakhir tidak bisa dikompilasi? Saya tidak melihat ketidakcocokan jenis.

— Sam Goldberg

2

Ini adalah tipe yang bergantung pada jalur Scala .

— Debilski

Sebenarnya, saya ingin membahas ini dari sudut pandang sistem tipe Scala. Kebetulan satu contoh yang diberikan dalam ceramah itu adalah di Jawa.

— Debilski

12

Sebenarnya, tipe path-dependent bersifat ortogonal ke struktural dan nominal mengetik. Tidak begitu jelas apa arti kelas dalam dalam konteks bahasa yang diketik secara struktural. Namun, sangat mungkin untuk mendefinisikan ini. Jika Anda mendefinisikan kelas dalam dalam konteks yang diketik secara struktural, Anda perlu memastikan bahwa kasus-kasus seperti yang Anda daftarkan akan ditolak (untuk alasan yang sama persis dengan yang ditolak Scala).

Anda akan menolak kasus seperti itu dengan melakukan hal yang sama seperti yang dilakukan Scala: memodelkan tipe path-dependent sebagai tipe eksistensial. Paket / pembungkusan prosedur yang sama seputar akses objek akan berlaku, dan hasilnya akan terlihat hampir sama dengan apa yang dilakukan Scala. Hasilnya mungkin tampak seperti kesetaraan jenis nominal, tetapi masih akan menjadi sistem jenis struktural karena pertanyaan tentang kompatibilitas jenis masih akan diputuskan pada antarmuka daripada nama.

Pengetikan struktural memang memiliki banyak implikasi, tetapi (mungkin mengejutkan) sebagian besar konsep yang sama yang kita semua tahu dan sukai dari sistem tipe nominal memang terbawa ke struktural. Pengetikan struktural tidak lebih dari cara yang berbeda dalam mendefinisikan kompatibilitas tipe.

— Daniel Spiewak
sumber

0

Pengetikan struktural membuatnya lebih mudah untuk menulis kode perpustakaan umum. Alasan # 1 mengapa ekosistem Java begitu membengkak adalah karena sulit untuk menulis perpustakaan kecil dengan mudah. Jika Jawa diketik secara struktural saya pikir itu akan menjadi cerita yang berbeda dan situasi yang jauh lebih baik.

Satu-satunya kelemahan yang dapat saya pikirkan untuk pengetikan struktural adalah potensi kompilasi yang lebih lambat. Saya tidak yakin apakah bahasa struktural umumnya mengkompilasi lebih lambat daripada yang nominatif atau tidak, tetapi misalnya Golang diketik secara struktural dan sangat cepat dalam kompilasi.

— Alexander Mills
sumber