İyi bir genel tip sistem

Java jeneriklerinin bazı önemli yollarla başarısız olduğu yaygın olarak kabul edilmektedir. Joker karakterlerin ve sınırların birleşimi bazı ciddi olarak okunamayan kodlara yol açtı.

Ancak, diğer dillere baktığımda, programcıların mutlu olduğu genel bir tip sistem bulamıyorum.

Aşağıdakileri böyle bir sistemin tasarım hedefleri olarak kabul edersek:

• Her zaman kolay okunur tip bildirimleri üretir
• Öğrenmesi kolay (kovaryans, kontravaryans vb.
• derleme zamanı hatalarının sayısını maksimuma çıkarır

Doğru olan bir dil var mı? Google’a gidersem, gördüğüm tek şey, tür sisteminin X dilinde nasıl berbat olduğuyla ilgili şikayetlerdir. Derleme zamanında% 100 tip güvenliği doğrulamaya çalışmaktan vazgeçmeli miyiz?

Asıl sorum, bu üç amaç için en iyi "doğru olanı" yapan dildir. Bunun öznel olduğunu fark ettim, ancak şu ana kadar programcıların genel tip sisteminin bir karışıklık olduğu konusunda hemfikir olmadığı bir dili bile bulamıyorum.

Zeyilname: belirtildiği gibi, alt türleme / kalıtım ve jeneriklerin birleşimi karmaşıklığı yaratan şeydir, bu yüzden gerçekten her ikisini birleştiren ve karmaşıklığın patlamasını önleyen bir dil arıyorum.

Jenerikler, fonksiyonel programlama topluluğunda onlarca yıldır yaygın olarak bulunurken, nesne yönelimli programlama dillerine jenerik madde eklemek, özellikle alt tipleme ve jenerikliğin etkileşimi gibi bazı benzersiz zorluklar sunmaktadır.

Bununla birlikte, nesne yönelimli programlama dillerine ve özellikle de Java'ya odaklansak bile, çok daha iyi bir jenerik sistem tasarlanabilirdi:

1. Diğer tipler nerede olursa olsun, genel türler kabul edilebilir olmalıdır. Özellikle, Tbir tür parametresiyse, aşağıdaki ifadeler uyarı vermeden derlenmelidir:

   object instanceof T; 
   T t = (T) object;
   T[] array = new T[1];
   

   Evet, bu, jeneriklerin tıpkı dildeki diğer tüm türler gibi yeniden birleştirilmesini gerektirir.

2. Genel türün kovaryansı ve karşıtlığı, genel türün her kullanımından ziyade bildiriminde belirtilmeli (veya çıktısından) belirtilmelidir,

   Future<Provider<Integer>> s;
   Future<Provider<Number>> o = s; 
   

   ziyade

   Future<? extends Provider<Integer>> s;
   Future<? extends Provider<? extends Number>> o = s;
   

3. Genel türler oldukça uzayabildiğinden, gereksiz olarak belirtmemize gerek kalmaz. Yani yazabilmeliyiz

   Map<String, Map<String, List<LanguageDesigner>>> map;
   for (var e : map.values()) {
       for (var list : e.values()) {
           for (var person : list) {
               greet(person);
           }
       }
   }
   

   ziyade

   Map<String, Map<String, List<LanguageDesigner>>> map;
   for (Map<String, List<LanguageDesigner>> e : map.values()) {
       for (List<LanguageDesigner> list : e.values()) {
           for (LanguageDesigner person : list) {
               greet(person);
           }
       }
   }
   

4. Herhangi bir tip sadece referans tiplerine değil, tip parametresi olarak kabul edilebilir olmalıdır. (Eğer sahip olabilirsek int[], neden sahip olamıyoruz List<int>?)?

Bunların hepsi C # ile mümkündür.

Alt programlama, genel programlama yaparken çok fazla komplikasyon yaratır. Alt tipleri olan bir dili kullanmakta ısrar ediyorsanız, jenerik programlamanın kendisiyle birlikte gelen kesin bir karmaşıklık olduğunu kabul etmek zorundasınız. Bazı diller diğerlerinden daha iyi yapar, ancak bunu yalnızca o kadar uzağa götürebilirsiniz.

Mesela Hasker'in jenerikleriyle karşılaştır. Tip çıkarımı kullanırsanız, kazayla doğru bir jenerik fonksiyon yazabilmeniz için yeterince basittir . Tek bir türünü belirtirseniz Aslında, derleyici genellikle kendisine diyor, "Eh, oldu bu yüzden ne olursa olsun, bu jenerik yapacak, ama sadece ints bunu yapmak istedi."

Kuşkusuz, insanlar kullanmak , bazı şaşırtıcı karmaşık şekillerde Haskell'ın tip sistemini bunu her acemi yıkım yapım ancak altta yatan tür sistemi kendisi zarif ve çok takdir olduğunu.

Generikleri yaklaşık 20 yıl önce devam eden alt tipleme ile birleştirmeye yönelik çok fazla araştırma yapıldı. Barbara Liskov'un MIT'deki araştırma grubu tarafından geliştirilen Thor programlama dili, üzerinde parametreleştirdiğiniz türün gereksinimlerini belirlemenize izin veren "where" cümleleri kavramına sahipti. (Bu, C ++ 'ın Concepts ile yapmaya çalıştığına benzer .)

Thor'un jenerikliğini ve Thor'un alt türleriyle nasıl etkileşimde bulunduklarını anlatan makale: Day, M; Gruber, R; Liskov, B; Myers, AC: Subtipler vs yan tümceler: parametrik polimorfizm kısıtlayıcı , Obj Odaklı Prog, Sys, Lang ve Apps ACM Konf , (OOPSLA-10): 156-158, 1995.

1980’lerin sonlarında Zümrüt’te yapılan çalışmaların inşa edildiğine inanıyorum. (Bu çalışmayı okumamıştım, ancak referans: Siyah, A; Hutchinson, N; Jul, E; Levy, H; Carter, L: Zümrüt Dağılım ve Soyut Tipleri , _IEEE T. Yazılım Müh., 13 ( 1): 65-76, 1987.

Hem Thor hem de Emerald “akademik diller” idi, bu yüzden insanların cümlelerin (kavramların) herhangi bir gerçek sorunu çözüp çözmediğini gerçekten anlamaları için muhtemelen yeterli bir kullanım elde edemediler. Bjarne Stroustrup'un C ++ 'da ilk Kavramları denemesinin neden başarısız olduğuna dair makalesini okumak ilginç: Stroustrup, B: C ++ 0x "Kavramları Kaldır" Kararı , Dr Dobbs , 22 Temmuz 2009. ( Stroustrup ana sayfasında daha fazla bilgi . )

İnsanların deniyor gibi göründüğü bir başka yön, özellik denilen bir şeydir . Örneğin Mozilla'nın Rust programlama dili özellikleri kullanır. Anladığım kadarıyla (tamamen yanlış olabilir), bir sınıfın bir özelliği sağladığını ilan etmek, bir sınıfın bir arayüz oluşturduğunu söylemek gibi bir şeydir, ancak siz "bir" yerine "gibi" davrandığını söylüyorsunuz. Apple'ın yeni Swift programlama dilleri benzer bir kavram kullanıyor görünüyor protokolleri için jenerik parametrelere kısıtlamaları belirleyen .