In che modo le coppie di protocollo/implementazione devono essere adattate alle linee guida di progettazione dell'API Swift?

Question

Nel nuovo Swift API design guidelines, il suffisso Type comunemente utilizzato per i protocolli viene eliminato. Mentre questo è facile da fare per i protocolli che sono stand-alone (SequenceType diventa Sequence), non sono sicuro di come aggiornare le mie API in cui un protocollo fornisce la base per un'implementazione. Ecco alcuni esempi di quadri famosi:

• Il Result μframework fornisce Result, un successo concreto/fail enumerazione, e ResultType, un protocollo di base generico per un successo/tipo di fallire, a quali Result conforme.
• ReactiveCocoa I tipi principali Signal e SignalProducer, che sono supportati da SignalType e SignalProducerType.

In entrambi i casi, gran parte dell'attuazione è nelle estensioni dei protocolli, consentendo estensioni sfruttare appieno la potenza dei vincoli di tipo, e permettendo implementazioni di essere generico. Questo è diverso dal caso dei protocolli con tipi di cancellazione del tipo di stile AnySequence: non si è veramente attesi per implementare questi protocolli da soli o unificare tipi disparati.

Answer 1

Si consiglia di utilizzare il suffisso Protocol. Ciò è coerente con il modo della libreria standard hanno messo a nudo la Type suffisso da protocolli, come indicato in SE-0006:

Su di alto livello, i cambiamenti possono essere riassunti come segue.

• suffisso Type dai nomi dei protocolli. In alcuni casi speciali, questo significa aggiungere un suffisso Protocol per evitare di utilizzare i nomi di tipo che sono primari (sebbene la maggior parte di questi aspetti siano obsoleti dalle funzionalità del linguaggio Swift 3 ).

Per esempio, GeneratorType è stato rinominato IteratorProtocol.

E, per esempio, è anche il modo sia Result & ReactiveSwift hanno aggiornato le loro API per Swift 3. ResultType è stato rinominato per ResultProtocol (in this commit), e SignalType stato rinominato in SignalProtocol, e SignalProducerType stato rinominato in SignalProducerProtocol (in this commit).

Anche se vale la pena notare che nella maggior parte di questi casi, tali protocolli esistono solo come soluzione alternativa per la mancanza di parameterised extensions.

Ad esempio, al momento non possiamo dire:

struct SomeGenericThing<T> { 
    var value: T 
} 

extension <T> Array where Element == SomeGenericThing<T>, T : Comparable { 

} 

ma introducendo un protocollo permette di realizzare il segnaposto generico (s) come tipo associato (s), che si può utilizzare in vincoli:

protocol SomeGenericThingProtocol { 
    associatedtype T 
    var value: T { get set } 
} 

struct SomeGenericThing<T> : SomeGenericThingProtocol { 
    var value: T 
} 

extension Array where Element : SomeGenericThingProtocol, Element.T : Comparable { 
    // ... 
} 

Pertanto, una volta supportate le estensioni parametrizzate, saremo in grado di eliminare tali protocolli.