Swift è stato progettato per colmare il divario tra le astrazioni a costo zero di C++ e la flessibilità dinamica di Objective-C. Le prime versioni si basavano fortemente sull'ereditarietà delle classi e sulle tabelle dei metodi virtuali, ma l'introduzione della programmazione orientata ai protocolli in Swift 2.0 ha reso necessario un modello di dispatch più sfumato. Il team del compilatore ha optato per un approccio ibrido in cui i requisiti del protocollo (metodi dichiarati nel corpo del protocollo) utilizzano tabelle di testimoni per il polimorfismo a runtime, mentre i metodi definiti esclusivamente nelle estensioni sono risolti staticamente. Questa decisione di design risale all'esigenza di supportare il modeling retroattivo e i tipi di valore senza sacrificare le caratteristiche di prestazione del dispatch statico.
Gli sviluppatori suppongono frequentemente che fornire un'implementazione di un metodo in un'estensione del protocollo crei un comportamento “predefinito” che i tipi conformi possono sovrascrivere in modo polimorfico. Tuttavia, Swift dispatcha i metodi delle estensioni staticamente in base al tipo del riferimento al momento della compilazione, non al tipo dell'istanza a runtime. Quando si utilizzano scatole esistenziali (any Protocol), il tipo al momento della compilazione è il contenitore esistenziale stesso, causando invocazioni che si risolvono all'implementazione dell'estensione indipendentemente da eventuali sovrascritture nei tipi concreti. Questo crea bug insidiosi in cui le implementazioni personalizzate nelle sottoclassi o nelle strutture vengono silenziosamente ignorate in collezioni eterogenee.
Per abilitare un vero polimorfismo dinamico, il metodo deve essere dichiarato come requisito del protocollo all'interno della dichiarazione del protocollo stesso. Ciò costringe il compilatore a allocare una voce nella tabella di testimoni per il metodo, consentendo al runtime di cercare la corretta implementazione attraverso la tabella di testimoni del tipo. Per algoritmi critici per le prestazioni in cui il polimorfismo non è necessario, i metodi dovrebbero rimanere nelle estensioni per consentire al compilatore di inlining o di eseguire altre ottimizzazioni statiche. Swift 5.6+ ha introdotto la sintassi esplicita della parola chiave any per rendere più visibile la cancellazione del tipo esistenziale, servendo come promemoria che le informazioni di tipo vengono perse e il dispatch statico predefinito si basa sull'estensione.
protocol Drawable { func draw() // Requisito: dispatch dinamico tramite tabella di testimoni } extension Drawable { func draw() { print("Default") } func render() { print("Static render") } // Estensione: dispatch statico solo } struct Circle: Drawable { func draw() { print("Circle") } func render() { print("Circle render") } } let shape: any Drawable = Circle() shape.draw() // Stampa "Circle" (dispatch dinamico) shape.render() // Stampa "Static render" (dispatch statico - ignora la versione di Circle!)
Stavamo sviluppando un motore di grafica vettoriale in cui varie forme si conformavano a un protocollo RenderCommand. Inizialmente, abbiamo aggiunto un metodo generatePreview() esclusivamente all'interno di un'estensione del protocollo per fornire una miniatura rasterizzata predefinita per tutte le forme. Tipi concreti come BezierCurve e Polygon hanno implementato i propri metodi generatePreview() ottimizzati che utilizzavano le loro specifiche proprietà geometriche per una rendering nitido. Quando abbiamo memorizzato queste forme in un array [any RenderCommand] per elaborare il pipeline di rendering, abbiamo scoperto che chiamare generatePreview() su ogni elemento produceva la stessa immagine predefinita sfocata piuttosto che le anteprime personalizzate di alta qualità.
Abbiamo considerato tre soluzioni distinte. Prima, avremmo potuto spostare generatePreview() nella dichiarazione del protocollo RenderCommand come un requisito formale. Questo approccio garantirebbe il dispatch dinamico attraverso la tabella di testimoni, garantendo la corretta risoluzione del metodo a runtime. Tuttavia, questo costringerebbe ogni tipo di forma a dichiarare esplicitamente il metodo nella sua conformità, sebbene potessimo mitigare il boilerplate mantenendo l'implementazione predefinita nell'estensione per i tipi che non necessitavano di personalizzazione.
In secondo luogo, avremmo potuto rifattorizzare il nostro pipeline per utilizzare generici con una firma di funzione come func process<T: RenderCommand>(commands: [T]) anziché utilizzare l'esistenziale [any RenderCommand]. Questo avrebbe preservato il dispatch statico alla corretta implementazione poiché Swift monomorfizza i generici al momento della compilazione, conservando le informazioni di tipo. Lo svantaggio era che non avremmo potuto più memorizzare tipi di forma eterogenei (mescolando BezierCurve e Polygon) in un singolo array senza implementare un wrapper di cancellazione del tipo, il che avrebbe aumentato notevolmente la complessità del codice.
In terzo luogo, avremmo potuto implementare il pattern Visitor per instradare manualmente le chiamate ai metodi al tipo concreto appropriato. Questo avrebbe evitato la modifica della definizione del protocollo nella sua interezza pur raggiungendo un comportamento polimorfico. Tuttavia, questa soluzione ha introdotto un sostanziale codice boilerplate e ha creato un onere di manutenzione ogni volta che nuovi tipi di forma venivano aggiunti al sistema.
Alla fine abbiamo scelto la prima soluzione perché il protocollo era interno al nostro modulo e la chiarezza del comportamento polimorfico era essenziale per la correttezza del motore di rendering. Aggiungere il requisito ha avuto un impatto trascurabile sulla dimensione del nostro binario e il lieve sovraccarico dell'indirizzamento della tabella di testimoni era impercettibile rispetto ai calcoli di rendering. Dopo aver implementato questa modifica, la generazione dell'anteprima ha correttamente utilizzato l'implementazione ottimizzata di ciascuna forma, eliminando gli artefatti visivi dall'interfaccia utente.
Perché una sottoclasse non può sovrascrivere un metodo che è stato definito solo in un'estensione del protocollo?
Quando un metodo è definito esclusivamente in un'estensione del protocollo e non dichiarato nel protocollo stesso, Swift non alloca una voce nella tabella di testimoni per esso. Il dispatch viene risolto staticamente al momento della compilazione in base al tipo di riferimento. Se una classe si conforma al protocollo e definisce un metodo con la stessa firma, crea un nuovo metodo non correlato che ombreggia il metodo di estensione anziché sovrascriverlo. Questo significa che quando viene accesso tramite un esistenziale del protocollo (any Protocol), l'implementazione dell'estensione del protocollo viene sempre chiamata, ignorando la versione della classe. Per ottenere un comportamento polimorfico, il metodo deve essere dichiarato nella dichiarazione del protocollo per diventare un requisito con dispatch dinamico.
Come influisce l'utilizzo di some (tipi di risultato opachi) invece di any sul dispatch per i metodi delle estensioni del protocollo?
Con some Drawable, il tipo concreto è conosciuto al momento della compilazione grazie alla monomorfizzazione dei generici di Swift. Quando si chiama un metodo di estensione su un tipo opaco, il compilatore può dispatchare staticamente all'implementazione del tipo concreto poiché le informazioni sul tipo sono preservate dietro le quinte, anche se nascoste chiamatore. Al contrario, any Drawable è una scatola esistenziale che annulla il tipo concreto, costringendo il compilatore a utilizzare l'implementazione predefinita dell'estensione per i metodi non di requisito. La differenza chiave è che some preserva il polimorfismo statico, consentendo al compilatore di inlinare o legarsi direttamente al metodo corretto, mentre any costringe una ricerca della tabella vtable a runtime solo per i requisiti e predefinisce a l'estensione per tutto il resto.
Qual è l'impatto sulla dimensione del binario e sulle prestazioni di convertire un metodo di estensione in un requisito del protocollo?
Convertire un metodo di estensione in un requisito del protocollo aggiunge un'entrata alla tabella dei testimoni del protocollo, aumentando la dimensione del binario di circa 8 byte per conformità su architetture a 64 bit. Ogni tipo conforme deve ora popolare questo slot nella sua tabella dei testimoni, aggiungendo un piccolo sovraccarico di memoria per tipo. Dal punto di vista delle prestazioni, i requisiti comportano un sovraccarico di chiamata indiretta attraverso la tabella dei testimoni (una dereferenziazione di puntatore aggiuntiva e un salto), mentre i metodi di estensione possono essere inlinati o chiamati direttamente senza sovraccarico. Tuttavia, la perdita dell'inlining per i requisiti è spesso compensata dal predittore di ramificazione della CPU, e il beneficio del corretto comportamento polimorfico supera di solito il costo in nanosecondi della chiamata indiretta nella maggior parte del codice applicativo.