Swift wprowadził @dynamicMemberLookup w wersji 4.2 w ramach SE-0195, aby zniwelować ergonomiczną przepaść między statycznymi systemami typów a dynamicznymi źródłami danych, takimi jak JSON lub interoperacyjność z językami skryptowymi. Przed tą funkcją programiści uzyskiwali dostęp do dynamicznych właściwości za pomocą werbalnych subskryptów słownikowych, co poświęcało zarówno czytelność, jak i bezpieczeństwo w czasie kompilacji. Propozycja miała na celu umożliwienie składni notacji kropkowej dla dynamicznych właściwości, jednocześnie zachowując silne zapewnienia systemu typów Swift.
Języki kompilowane statycznie wymagają wiedzy o nazwach właściwości w czasie kompilacji, aby wygenerować poprawny kod maszynowy, co uniemożliwia bezpośrednie użycie notacji kropkowej do struktur danych, których schemat znany jest tylko w czasie wykonywania. Tradycyjne podejścia zmuszały do wyboru między bezpieczeństwem typów (definiowanie sztywnych struktur) a elastycznością (używaniem niestrukturalnych słowników), przy czym żadne z nich nie zaspokajało potrzeby ergonomicznego, a jednocześnie bezpiecznego dostępu do dynamicznych danych. Wyzwanie polegało na stworzeniu mechanizmu, który odkłada rozwiązanie nazw na czas wykonywania, nie rezygnując z statycznego sprawdzania typów dla zwracanych wartości.
Kompilator syntetyzuje specjalną metodę subskryptu subscript(dynamicMember:), która akceptuje zarówno String, jak i KeyPath i zwraca wartość o typie ogólnym. Kiedy kompilator napotyka nierozwiązany dostęp do właściwości w typie oznaczonym jako @dynamicMemberLookup, przepisuje wyrażenie na wywołanie tego subskryptu, używając nazwy właściwości jako argumentu. Typ zwracany jest określany statycznie w miejscu wywołania poprzez inferencję typów lub explicytną adnotację, co zapewnia, że podczas gdy nazwa właściwości jest rozwiązywana dynamicznie, wartość wyniku musi odpowiadać oczekiwanemu statycznemu typowi.
@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 // Rozwiązane za pomocą dynamicMemberLookup
Musieliśmy stworzyć SDK klienta dla zewnętrznego API analitycznego, które zwracało metadane zdarzeń z różnymi schematami w zależności od typu zdarzenia. API zwracało ponad pięćdziesiąt różnych typów zdarzeń, z unikalnymi właściwościami, co czyniło definiowanie statycznych struktur nieopłacalnym, ponieważ API ewoluowało co tydzień.
Opis problemu:
Programiści korzystali z zagnieżdżonych słowników [String: [String: Any]], aby uzyskać dostęp do właściwości, takich jak event["properties"]["user_id"], co skutkowało częstymi awariami w czasie wykonywania z powodu literówek w kluczach stringowych i niezgodności typów. Próby wygenerowania ponad pięćdziesięciu struktur za pomocą Codable były podejmowane, ale wymagały ponownej implementacji SDK przy każdej drobnej zmianie w API, tworząc wąskie gardło w utrzymaniu.
Rozwiązanie A: Polimorfizm zorientowany na protokoły
Rozważaliśmy zdefiniowanie protokołu AnalyticsEvent z wspólnymi polami i konkretnymi strukturami dla każdego typu zdarzenia. Zalety: Pełne bezpieczeństwo w czasie kompilacji i autouzupełnianie. Wady: Ogromna duplikacja kodu, eksplozja rozmiaru binarnego i wymuszone ponowne wprowadzenie przy pojawieniu się nowych zdarzeń.
Rozwiązanie B: Słowniki z typami stringowymi
Kontynuowanie dostępu za pomocą surowych słowników. Zalety: Maksymalna elastyczność, brak potrzeby generowania kodu. Wady: Brak ochrony przed literówkami, takimi jak user_ud, awarie rzutowania w czasie wykonywania i słabe doświadczenia programistów.
Rozwiązanie C: Wrapper @dynamicMemberLookup
Utworzenie cienkiego wrappera wokół surowego JSON-a przy użyciu @dynamicMemberLookup z typowanymi subskryptami. Zalety: Ergonomia notacji kropkowej (event.properties.userId), walidacja typów w czasie kompilacji przy określonych typach oraz odporność na zmiany schematów. Wady: Brak autouzupełniania IDE dla dynamicznych kluczy, niewielki narzut w czasie wykonywania dla haszowania stringów oraz potencjalne błędy w czasie wykonywania dla brakujących kluczy.
Wybrane rozwiązanie i wynik:
Wybraliśmy Rozwiązanie C, ponieważ zyski w szybkości rozwoju przewyższały ograniczenia autouzupełniania. Wymagając explicytnych adnotacji typów (let id: String = event.userId), wychwytywaliśmy 90% błędów typów w czasie kompilacji. Testy jednostkowe weryfikowały istnienie kluczy. Wynikiem była 60% redukcja awarii w czasie wykonywania związanych z analizą zdarzeń oraz wzrost satysfakcji programistów z wynikiem z 4.2 do 4.8 na 5.
Kiedy typ używa @dynamicMemberLookup i jednocześnie deklaruje konkretną właściwość o tej samej nazwie co dynamiczny klucz, który dostęp ma pierwszeństwo i dlaczego?
Deklaracja konkretnej właściwości zawsze ma pierwszeństwo przed dynamicznym subskryptem. Rozwiązywanie nazw w Swift podąża za ścisłą hierarchią: najpierw przeszukuje jawnie zadeklarowane członki w definicji typu i jego rozszerzeniach, następnie sprawdza wymagania protokołu, a tylko jeśli nie znajdzie dopasowania, rozważa alternatywy @dynamicMemberLookup. To zapewnia, że dynamiczne przeszukiwanie nie może przypadkowo przesłonić lub nadpisać intencjonalnych umów API, utrzymując przewidywalność w interfejsach typów.
Czy @dynamicMemberLookup może wspierać heterogeniczne typy zwracane, gdzie różne klucze zwracają różne typy, i jak kompilator rozwiązuje niejednoznaczność?
Tak, poprzez przeciążenie metody subscript(dynamicMember:) z różnymi ograniczeniami typów zwracanych lub przy użyciu ogólnych subskryptów z inferencją typów. Jednak kompilator musi być w stanie jednoznacznie określić typ zwracany na podstawie kontekstu w miejscu wywołania. Jeśli config.name mogłoby zwrócić zarówno String, jak i Int w zależności od różnych przeciążeń, kod nie skompiluje się bez explicytnych adnotacji typów (np. let name: String = config.name). Swift używa kontekstowych informacji typowych, aby wybrać odpowiednie przeciążenie subskryptu w czasie kompilacji.
Jaki jest podstawowy koszt wydajności dostępu do dynamicznych członków w porównaniu z dostępem do statycznych właściwości i co powoduje ten narzut?
Dostęp do dynamicznych członków wiąże się z kosztem haszowania stringów i potencjalnego wyszukiwania w słowniku lub wywołania metody, podczas gdy dostęp statyczny używa obliczonych w czasie kompilacji przesunięć pamięci. Przy dostępie do object.property, statyczne rozwiązywanie typowo ma złożoność O(1) z bezpośrednim przesunięciem wskaźnika, podczas gdy dynamiczne rozwiązywanie wymaga haszowania nazwy właściwości (O(n), gdzie n to długość stringa) i wyszukiwania wartości w zapleczu. Dodatkowo, implementacja dynamicznego subskryptu może wprowadzać dodatkowy ruch retain/release lub opakowywanie egzystencjalne, w zależności od implementacji zwracanego typu, podczas gdy dostęp statyczny można zoptymalizować przez kompilator w wielu kontekstach.