guidelines - swift api docs

¿Cómo deben ajustarse los pares de protocolo/implementación para las directrices de diseño de Swift API?

Question

En las nuevas directrices de diseño de Swift API , se está eliminando el sufijo de Type comúnmente usado para protocolos. Si bien esto es fácil de hacer para los protocolos que son independientes ( SequenceType convierte en Sequence ), no estoy seguro de cómo actualizar mis API en las que un protocolo proporciona la base para una implementación. Aquí hay algunos ejemplos de marcos populares:

• El µframework del Result proporciona un Result , una enumeración concreta de éxito / error, y ResultType , un protocolo genérico base para un tipo de éxito / error, al que corresponde el Result .
• ReactiveCocoa principales tipos de ReactiveCocoa son Signal y SignalProducer , que están respaldados por SignalType y SignalProducerType .

En ambos casos, gran parte de la implementación está en extensiones de los protocolos, lo que permite que las extensiones utilicen todo el poder de las restricciones de tipo y permite que las implementaciones sean genéricas. Esto es diferente del caso de los protocolos con tipos de borrado de tipo de estilo AnySequence : realmente no se espera que implementes estos protocolos por tu cuenta, o que unifiques tipos dispares.

Answer 1

Yo aconsejaría usar el sufijo Protocol . Esto es consistente con la forma en que la biblioteca estándar ha eliminado el sufijo Type de los protocolos, como se indica en SE-0006 :

En alto nivel, los cambios se pueden resumir de la siguiente manera.

• Tira el sufijo de Type de nombres de protocolo. En algunos casos especiales, esto significa agregar un sufijo de Protocol para evitar los nombres de tipo que son primarios (aunque la mayoría de estos esperamos que queden obsoletos por las características del lenguaje Swift 3).

Por ejemplo, GeneratorType fue renombrado a IteratorProtocol .

Y, por ejemplo, también es así como Result y ReactiveSwift han actualizado sus API para Swift 3. ResultType se cambió de nombre a ResultProtocol (en este compromiso ), y SignalType se cambió de nombre a SignalProtocol , y SignalProducerType se cambió a SignalProducerProtocol (en este compromiso ).

Aunque vale la pena señalar que en la gran mayoría de estos casos, tales protocolos solo existen como una solución para la falta de extensiones parametrizadas .

Por ejemplo, actualmente no podemos decir:

struct SomeGenericThing<T> {
    var value: T
}

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

}

Pero la introducción de un protocolo nos permite realizar los marcadores de posición genéricos como tipo (s) asociado (s), que luego podemos usar en restricciones:

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

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

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

Por lo tanto, una vez que se admitan extensiones parametrizadas, podremos eliminar tales protocolos.