Swift is ontworpen om de kloof te overbruggen tussen de nul-kosten abstracties van C++ en de dynamische flexibiliteit van Objective-C. Vroege versies vertrouwden sterk op klasse-erfelijkheid en virtuele methode tabellen, maar de introductie van protocol-georiënteerd programmeren in Swift 2.0 vereiste een verfijndere dispatch model. Het compilerteam koos voor een hybride benadering waarbij protocol vereisten (methoden die in het protocollichaam zijn gedeclareerd) getuigen-tabellen gebruiken voor runtime polymorfisme, terwijl methoden die uitsluitend in extensies zijn gedefinieerd statisch worden opgelost. Deze ontwerpbeslissing gaat terug op de noodzaak om retroactieve modellering en waarde types te ondersteunen zonder de prestatiekenmerken van statische dispatch in gevaar te brengen.
Ontwikkelaars gaan er vaak van uit dat het bieden van een methode-implementatie in een protocol-extensie een "standaard" gedrag creëert dat de conformerende types polymorfisch kunnen overschrijven. Echter, Swift dispatches extensiemethoden statisch op basis van het compileertijdtype van de referentie, niet het runtime-type van de instantie. Bij het gebruik van existentiële dozen (any Protocol), is het compileertijdtype de existentiële container zelf, waardoor aanroepen worden opgelost naar de implementatie van de extensie, ongeacht eventuele overschrijvingen in concrete types. Dit creëert sluipende bugs waarbij aangepaste implementaties in subklassen of structs stilletjes worden omzeild in heterogene collecties.
Om echte dynamische polymorfisme mogelijk te maken, moet de methode worden gedeclareerd als een protocol vereiste binnen de protocolverklaring zelf. Dit dwingt de compiler om een getuigen-tabellentry voor de methode toe te wijzen, zodat de runtime de juiste implementatie via de getuigen-tabel kan opzoeken. Voor prestatiekritieke algoritmen waar polymorfisme niet nodig is, moeten methoden in extensies blijven om de compiler in staat te stellen ze in te lijnen of andere statische optimalisaties uit te voeren. Swift 5.6+ introduceerde de expliciete any sleutelwoord syntaxis om het bestaan van type-erasure zichtbaarder te maken, als een herinnering dat type-informatie verloren gaat en statische dispatch standaard op de extensie terugvalt.
protocol Drawable { func draw() // Vereiste: dynamische dispatch via getuigen-tabel } extension Drawable { func draw() { print("Standaard") } func render() { print("Statische weergave") } // Extensie: alleen statische dispatch } struct Circle: Drawable { func draw() { print("Cirkel") } func render() { print("Cirkelweergave") } } let shape: any Drawable = Circle() shape.draw() // Print "Cirkel" (dynamische dispatch) shape.render() // Print "Statische weergave" (statische dispatch - negeert de versie van Cirkel!)
We ontwikkelden een vector graphics engine waarbij verschillende vormen zich conformeerden aan een RenderCommand protocol. Aanvankelijk voegden we een generatePreview() methode uitsluitend binnen een protocolextensie toe om een standaard gerasteriseerde thumbnail voor alle vormen te bieden. Concrete types zoals BezierCurve en Polygon implementeerden hun eigen geoptimaliseerde generatePreview() methoden die hun specifieke geometrische eigenschappen gebruikten voor scherpe rendering. Toen we deze vormen opsloegen in een [any RenderCommand] array om de rendering-pijplijn te verwerken, ontdekten we dat het aanroepen van generatePreview() op elk element dezelfde vage standaardafbeelding produceerde in plaats van de gepersonaliseerde hoogwaardige previews.
We overweegden drie verschillende oplossingen. Ten eerste konden we generatePreview() in de RenderCommand protocolverklaring verplaatsen als een formele vereiste. Deze benadering zou dynamische dispatch via de getuigen-tabel garanderen, wat de juiste methode-resolutie tijdens runtime zou waarborgen. Echter, dit zou elke vormtype dwingen om de methode expliciet te declareren in zijn conformiteit, hoewel we de boilerplate konden verminderen door de standaardimplementatie in de extensie te behouden voor types die geen aanpassing nodig hadden.
Ten tweede konden we onze pijplijn refactoren om generics te gebruiken met een functietekening zoals func process<T: RenderCommand>(commands: [T]) in plaats van het gebruik van het existentiële [any RenderCommand]. Dit zou de statische dispatch naar de juiste implementatie behouden omdat Swift generics tijdens compileertijd monomorfiseert, waardoor type-informatie behouden blijft. Het nadeel was dat we heterogene vormtypes (mixen van BezierCurve en Polygon) niet meer in één enkele array konden opslaan zonder een type-erasure wrapper te implementeren, wat de codecomplexiteit aanzienlijk zou verhogen.
Ten derde konden we het Visitor patroon implementeren om methoden handmatig naar het juiste concrete type te routeren. Dit zou verhinderen dat de protocoldefinitie volledig werd gewijzigd terwijl nog steeds polymorf gedrag werd bereikt. Deze oplossing introduceerde echter aanzienlijke boilerplatecode en creëerde een onderhoudsbelastingen telkens wanneer nieuwe vormtypes aan het systeem werden toegevoegd.
We kozen uiteindelijk voor de eerste oplossing omdat het protocol intern was voor onze module, en de duidelijkheid van polymorf gedrag essentieel was voor de correctheid van de rendering engine. Het toevoegen van de vereiste had een verwaarloosbare impact op de binaire grootte, en de lichte overhead van getuigen-tabel indirectie was niet waarneembaar vergeleken met de rendering berekeningen. Na het implementeren van deze wijziging werd de preview-generatie correct gebruik gemaakt van elke vorm's geoptimaliseerde implementatie, waarbij de visuele artefacten uit de gebruikersinterface werden geëlimineerd.
Waarom kan een subklasse een methode die alleen in een protocolextensie is gedefinieerd niet overschrijven?
Wanneer een methode uitsluitend in een protocolextensie is gedefinieerd en niet in het protocol zelf is gedeclareerd, Swift niet een getuigen-tabelentry daarvoor toewijzen. Dispatch wordt statisch tijdens de compileertijd opgelost op basis van het referentietype. Als een klasse voldoet aan het protocol en een methode met dezelfde handtekening definieert, creëert dit een nieuwe, ongebruikte methode die de extensiemethode overschaduwt in plaats van deze te overschrijven. Dit houdt in dat wanneer deze wordt benaderd via een protocol existentiële (any Protocol), de implementatie van de protocolextensie altijd wordt aangeroepen, waarbij de versie van de klasse wordt genegeerd. Om polymorf gedrag te bereiken, moet de methode in de protocolverklaring worden gedeclareerd om een vereiste met dynamische dispatch te worden.
Hoe beïnvloedt het gebruik van some (opake resultaattypen) in plaats van any de dispatch voor protocolextensiemethoden?
Met some Drawable, is het concrete type bekend tijdens de compileertijd vanwege de monomorfisatie van generics in Swift. Wanneer een extensiemethode op een opake type wordt aangeroepen, kan de compiler statisch dispatchen naar de implementatie van het concrete type omdat de type-informatie achter de schermen behouden blijft, zelfs als deze voor de aanroeper verborgen is. In tegenstelling tot any Drawable, is een existentiële doos die het concrete type wist, waardoor de compiler gedwongen wordt om de standaardimplementatie van de protocolextensie te gebruiken voor niet-vereiste methoden. Het belangrijkste verschil is dat some statische polymorfisme behoudt, waardoor de compiler kan inlinen of rechtstreeks binden aan de juiste methode, terwijl any alleen een runtime vtable lookup afdwingt voor vereisten en standaard op de extensie terugvalt voor alles eromheen.
Wat is de impact op de binaire grootte en de prestaties van het omzetten van een extensiemethode in een protocolvereiste?
Het omzetten van een extensiemethode in een protocolvereiste voegt een entry toe aan de getuigen-tabel van het protocol, wat de binaire grootte met ongeveer 8 bytes per conformiteit in 64-bits architecturen vergroot. Elk conformerend type moet nu deze slot in zijn getuigen-tabel invullen, wat een kleine geheugentoename per type toevoegt. Qua prestaties brengen vereisten een indirecte aanroep overhead met zich mee via de getuigen-tabel (één extra pointer dereferentie en sprongetje), terwijl extensiemethoden kunnen worden ingevoerd of direct kunnen worden aangeroepen met nul overhead. Echter, het verlies van inlining voor vereisten wordt vaak gecompenseerd door de CPU's takvoorspeller, en het voordeel van correct polymorf gedrag weegt meestal zwaarder dan de nanoseconde kost van de indirecte aanroep in de meeste applicatiecode.