Go'nun tür sistemi, her somut türün, O(1) arayüz yönlendirmesini sağlamak için sonlu, statik olarak belirlenebilir bir yöntem kümesine sahip olmasını zorunlu kılar. Eğer bir nesne üzerindeki genel olmayan bir alıcı kendi tür parametrelerini tanımlayabilseydi — örneğin, func (t *MyType) Process[T any](x T) — bu tür teorik olarak her mümkün tür argümanı T için tembel bir şekilde oluşturulan sonsuz bir yöntem kümesi sergilerdi.
Bu tasarım, yöntem işaretçileri için sabit ofsetlere dayanan itab (aracılar tablosu) düzeni garantilerini yok ederdi. Go'da tür parametrelerinin yalnızca tür tanımı ile sınırlı olmasını sağlayarak (örn. type MyType[T any] struct{}), her ayrı instantiation'ın derleme zamanında tam, sonlu bir meta veri tablosu üretmesini garanti eder. Bu, ikili boyut tahmin edilebilirliğini korur ve arayüz çağrılarının performans niteliklerini statik yönlendirme yoluyla sürdürür.
Yüksek verimli bir telemetri hattı tasarlarken, ekibimiz farklı veri türlerini — sayıcılar, histogramlar ve ölçümler — alabilen merkezi bir MetricCollector'a ihtiyaç duydu ve derleme zamanında tür güvenliğini korudu. Başlangıçta, collector.Record[T Metric](value T) gibi bir API istemiştik, burada MetricCollector somut bir tür olarak kalıyordu ve kullanıcıların kendilerini toplayıcıyı parametrize etme zorunluluğundan kurtarıyordu.
Sorun hemen ortaya çıktı: Go, yöntem seviyesinde tür parametresini reddetti ve bize tür silme ( any saklamak ve tür dönüşümü yapmak) ya da toplayıcıyı birden fazla genel örneğe parçalama arasında seçim yapmamızı zorladı. Üç ayrı yaklaşımı değerlendirdik.
İlk olarak, MetricCollector'ı genel bir tür MetricCollector[T Metric] olarak yükseltmeyi düşündük. Bu, func (mc *MetricCollector[T]) Record(value T) yöntemine izin verecekti. Artıları: Tam tür güvenliği ve sıfır tahsis maliyeti. Eksileri: Kullanıcıların sayıcılar ile ölçümler için ayrı toplayıcı örneklerine ihtiyaç duyması; bu durum, karışık metrikleri tek bir kayıttan toplama yeteneğini ortadan kaldırıyordu.
İkincisi, her metrik türü için RecordCounter, RecordGauge, vb. gibi monomorfize yöntemler oluşturmak için go:generate kullanarak kod üretimini keşfettik. Artıları: Tek bir toplayıcı örneği ile tür güvenli yöntemler. Eksileri: Derleme zamanı karmaşıklığı, şişirilmiş kaynak kontrolü ve yeni metrik türleri ortaya çıktığında kodu yeniden üretme gerekliliği.
Üçüncü olarak, tür parametresini alıcıdan ayıran paket düzeyinde genel bir fonksiyon func Record[T Metric](c *MetricCollector, value T) ile ilerledik. Artıları: Tek bir toplayıcı örneğini korudu, fonksiyonun derleyici monomorfizasyonu sayesinde tür güvenliğini sürdürdü ve arayüz masraflarından kaçındı. Eksileri: Kullanıcıların toplayıcıyı yöntem alıcısı yerine açık bir argüman olarak geçmelerini gerektiren biraz daha az idiyomatik "nesne yönelimli" sözdizimi.
Üçüncü çözümü seçtik çünkü bu, API ergonomisini Go'nun mimari kısıtlamaları ile dengeledi. Sonuç, çeşitli metrik türlerini tek bir arayüz aracılığıyla işleyebilen bir toplayıcı oldu ve tüm tür uyumsuzlukları üretim dağıtımları sırasında değil, derleme zamanında yakalandı.
type Metric interface { Type() string } type MetricCollector struct { storage map[string][]any } // Geçersiz: func (mc *MetricCollector) Record[T Metric](value T) // Geçerli: Açık bir toplayıcı argümanına sahip genel bir fonksiyon func Record[T Metric](mc *MetricCollector, value T) { key := value.Type() mc.storage[key] = append(mc.storage[key], value) }
Neden Go, func (t *Tree[T]) Insert(x T) gibi yöntemlere izin veriyor da func (t *Tree) Insert[T](x T)'yi reddediyor?
Alıcı kendisi genel olduğunda (Tree[T]), yöntem kümesi her bir belirli tür argümanı için somut olarak oluşturulur (örn. Tree[int]'in Insert(x int) adında bir yöntemi vardır). Yöntem seti sonlu kalır çünkü o programda bulunan sonlu instantiation'lara bağlıdır. Genel olmayan bir alıcı için, Insert[T]'ye izin vermek, sonsuz bir tür evreni tarafından dizinlenen açık uçlu bir yöntem ailesini ima ederdi ve bu da Go'nun statik bağlama ve hızlı arayüz çağrısı garantilerini ihlal eden çalışma zamanında yöntem sözlükleri ya da dinamik yönlendirme tablolarını gerektirirdi.
Somut türler genel yöntemleri destekleseydi arayüz tatmini nasıl bozulurdu?
Go'da arayüz tatmini, statik bir kontrol gerektirir: derleyici, bir türün arayüzü uygulayıp uygulamadığını yöntem imzalarını karşılaştırarak doğrular. Eğer MyType Method[T]() tanımlayabilseydi, o zaman interface { Method[int]() } ile interface { Method[string]() } tatmin etme durumları farklı olurdu. Derleyici sonsuz vtable varyasyonları oluşturmak ya da tatmin kontrollerini çalışma zamanına ertelemek zorunda kalırdı ve bu da arayüz çağrılarını basit işaretçi ofset aramaları yerine pahalı dinamik çözümlemelere dönüştürerek dilin performans modelini köklü bir şekilde değiştirirdi.
Somut türler üzerinde yapısal alanlar kullanarak tür parametreleri taklit edilebilir mi?
Evet, ama kritik anlamsal takaslarla. type Processor struct { handle func[T any](T) } tanımlanabilir, ancak bu, parametreli bir yöntemin dışında bir işlevin somut bir ikili instantiation'ını depolar. Alternatif olarak, reflect.Type'den işlevlere bir harita saklanabilir. Artıları: Çalışma zamanı esnekliği. Eksileri: Derleme zamanı tür güvenliğini kaybetmek, yansıtma maliyeti eklemek ve yapının artık yöntemini içermemesi nedeniyle arayüz soyutlamasını bozmak — yalnızca bir alan olduğu için — bu da türün o işlemi gerektiren arayüzleri tatmin etmesini engeller.