Swift, SE-0195 aracılığıyla sürüm 4.2'de @dynamicMemberLookup özelliğini tanıtarak, statik tür sistemleri ile dinamik veri kaynakları, örneğin JSON veya betik dili etkileşimi arasındaki ergonomik boşluğu gidermeyi amaçladı. Bu özelliğin öncesinde, geliştiriciler dinamik özelliklere, hem okunabilirliği hem de derleme zamanı güvenliğini feda ederek kelime dağarcığını kullanarak erişiyorlardı. Öneri, dinamik özellikler için nokta notasyonu sözdizimini mümkün kılarken, Swift'in güçlü tür sistemi garantilerini korumayı hedefliyordu.
Statik derlenmiş diller, geçerli makine kodu üretmek için özellik adlarının derleme zamanında bilinmesini gerektirir, bu da yalnızca çalışma zamanında bilinen veri yapıları için nokta notasyonu kullanımını doğrudan engeller. Geleneksel yaklaşımlar, tür güvenliği (katı yapılar tanımlamak) ve esneklik (türsüz sözlükler kullanmak) arasında bir seçim yapılmasını zorunlu kılarken, her iki yaklaşım da dinamik verilere ergonomik ama güvenli erişim ihtiyacını karşılamıyordu. Problemin çözümü, değerlerin döndürüldüğü yer için statik tür kontrolünü terk etmeden, isim çözümlemesini çalışma zamanına erteleyen bir mekanizma yaratmaktı.
Derleyici, ya bir String ya da KeyPath alan subscript(dynamicMember:) adında özel bir alt dize yöntemi sentezler ve genel türde bir değer döndürür. Derleyici, @dynamicMemberLookup ile işaretlenmiş bir türde herhangi bir çözümlenmemiş özellik erişimiyle karşılaştığında, ifadenin alt dizelerini bu özel alt dizeyi çağıracak şekilde yeniden yazar ve özellik adını argüman olarak kullanır. Dönüş türü, çağrı yerinde tür çıkarımı veya açık notasyon aracılığıyla statik olarak belirlenir, bu da özellik adının dinamik olarak çözümlenmesi sağlarken, elde edilen değerin beklenen statik türe uymasını garanti eder.
@dynamicMemberLookup struct Configuration { private var storage: [String: Any] init(_ storage: [String: Any]) { self.storage = storage } subscript<T>(dynamicMember member: String) -> T? { return storage[member] as? T } } let config = Configuration(["timeout": 30, "host": "localhost"]) let timeout: Int? = config.timeout // DinamikMemberLookup aracılığıyla çözümlendi
Üçüncü taraf bir analitik API'si için, olay türüne bağlı olarak değişen şemalarla olay meta verileri döndüren bir istemci SDK'sı geliştirmemiz gerekiyordu. API, her biri benzersiz özelliklere sahip elliden fazla farklı olay türü döndürdü, bu da statik yapı tanımlarını API haftalık evrimi ile sürdürülemez hale getirdi.
Problem Tanımı:
Geliştiriciler, event["properties"]["user_id"] gibi özelliklere erişmek için iç içe sözlükler [String: [String: Any]] kullanıyordu, bu da dize anahtarlarında yazım hatası ve tür uyuşmazlıkları nedeniyle sık sık çalışma zamanı çökmesine neden oluyordu. Elli'yi aşkın yapı oluşturarak Codable kullanmayı denedik ancak her küçük API değişikliği için SDK'yı yeniden dağıtmayı gerektiriyordu, bu da bakım darboğazı yaratıyordu.
Çözüm A: Protokol odaklı çok biçimlilik
Ortak alanlara sahip bir AnalyticsEvent protokolü tanımlamayı ve her olay türü için somut yapılar oluşturmayı düşündük. Artıları: Tam derleme zamanı güvenliği ve otomatik tamamlama. Eksileri: Büyük kod tekrarı, ikili boyut artışı ve yeni olaylar çıktığında zorunlu yeniden dağıtım.
Çözüm B: Dizeye dayalı sözlükler
Ham sözlük erişimi ile devam etme. Artıları: Maksimum esneklik, kod üretimine gerek yok. Eksileri: user_ud gibi yazım hatalarına karşı koruma yok, çalışma zamanı dönüştürme çökmeleri ve zayıf geliştirici deneyimi.
Çözüm C: @dynamicMemberLookup sargısı
Ham JSON etrafında @dynamicMemberLookup ile yazılı alt dizilerle ince bir sargı oluşturma. Artıları: Nokta sözdizimi ergonomisi (event.properties.userId), belirtilmiş türler sağlandığında derleme zamanı tür doğrulaması ve şema değişikliklerine dayanıklılık. Eksileri: Dinamik anahtarlar için IDE otomatik tamamlama yok, dize hashleme için hafif çalışma zamanı yükü ve eksik anahtarlar için potansiyel çalışma zamanı hataları.
Seçilen çözüm ve sonuç:
Otomatik tamamlama sınırlamasının, gelişim hızındaki kazanımlardan daha önemsiz olduğu için Çözüm C'yi seçtik. Açık tür notasyonları gerektirerek (let id: String = event.userId), tür hatalarının %90'ını derleme zamanında yakaladık. Birim testleri anahtar varlığını doğruladı. Sonuç olarak, olay ayrıştırma ile ilgili çalışma zamanı çökmesinde %60 azalma ve geliştirici memnuniyetinde 4.2'den 4.8'e bir artış elde edildi.
Bir tür @dynamicMemberLookup kullanıyorsa ve dinamik bir anahtar ile aynı ada sahip somut bir özellik açıklıyorsa, hangi erişim önceliğe sahip ve neden?
Somut özellik tanımı her zaman dinamik alt dize üzerinde önceliğe sahiptir. Swift'in isim çözümlemesi katı bir hiyerarşiyi takip eder: önce, tür tanımında ve genişletmelerindeki açıkça tanımlanmış üyeleri arar, ardından protokol gereksinimlerini kontrol eder ve yalnızca bir eşleşme bulunamazsa @dynamicMemberLookup geri dönüşlerini dikkate alır. Bu, dinamik aramanın yanlışlıkla kasıtlı API sözleşmelerini gölgede bırakmasını veya geçersiz kılmasını engelleyerek, tür arayüzlerinde öngörülebilirliğin korunmasını sağlar.
@dynamicMemberLookup, farklı anahtarların farklı türler döndürdüğü heterojen dönüş türlerini destekleyebilir mi ve derleyici belirsizliği nasıl çözer?
Evet, subscript(dynamicMember:) yöntemini farklı döndürme türü kısıtlamaları ile aşırı yükleyerek veya tür çıkarımı ile genel alt diziler kullanarak bunu sağlayabilir. Ancak, derleyicinin çağrı yerindeki bağlamdan döndürme türünü tartışmasız belirleyebilmesi gerekir. Eğer config.name farklı aşırı yüklemelere göre ya String ya da Int döndürebiliyorsa, açık tür notasyonu olmadan kod derlenmeyecektir (örneğin, let name: String = config.name). Swift, bağlamsal tür bilgisini kullanarak derleme zamanında uygun alt dize aşırı yüklemesini seçer.
Dinamik üye erişiminin statik özellik erişimine göre temel performans maliyeti nedir ve bu aşım neyi gerektirir?
Dinamik üye erişimi, dize hashleme ve potansiyel sözlük araması veya yöntem dağıtımı maliyetini taşır; oysa statik erişim, derleme zamanı hesaplanan bellek ofsetlerini kullanır. object.property erişiminde, statik çözümleme genellikle doğrudan işaretçi ofseti ile O(1) iken, dinamik çözümleme, özellik adı dizesinin hashlenmesini (O(n) burada n, dize uzunluğu) ve değerin bir destekleme deposunda aranmasını gerektirir. Ayrıca, dinamik alt dize uygulaması, dönüş türünün uygulamasına göre ekstra saklama/serbest bırakma trafiği veya varoluşsal kutulama getirebilirken, statik erişim birçok bağlamda derleyici tarafından optimize edilebilir.