Подтвердить что ты не робот

Как должны быть согласованы пары протоколов/реализации для руководящих принципов разработки Swift API?

В новом Руководстве по разработке Swift API обычно используется суффикс Type для протоколов. Хотя это легко сделать для автономных протоколов (SequenceType становится Sequence), я не уверен, как обновлять мои API, в которых протокол предоставляет базу для реализации. Вот несколько примеров из популярных фреймворков:

  • Result μframework предоставляет Result, конкретную перечисление успеха/неудачи и ResultType, общий базовый протокол для типа успеха/сбоя, к которому соответствует Result.
  • ReactiveCocoa основные типы Signal и SignalProducer, которые поддерживаются SignalType и SignalProducerType.

В обоих случаях большая часть реализации заключается в расширениях протоколов, позволяя расширениям использовать полную мощность ограничений типов и позволяя реализациям быть универсальными. Это отличается от протоколов с типом стирания типа AnySequence: вы не должны сами реализовать эти протоколы или унифицировать разрозненные типы.

4b9b3361

ОТВЕТЫ

Ответ 1

Я бы посоветовал использовать суффикс Protocol. Это согласуется с тем, как стандартная библиотека разделила суффикс Type от протоколов, как указано в SE-0006:

На высоком уровне изменения можно суммировать следующим образом.

  • Строка Type суффикса из имен протоколов. В нескольких особых случаях это означает добавление суффикса Protocol, чтобы исключить тип имен типов которые являются первичными (хотя большинство из них мы ожидаем, что будем устаревать Swift 3).

Например, GeneratorType было переименовано в IteratorProtocol.

И, например, также как и Result и ReactiveSwift обновили свои API для Swift 3. ResultType было переименовано в ResultProtocol (в this commit), а SignalType было переименовано в SignalProtocol, а SignalProducerType было переименовано в SignalProducerProtocol (в this commit).

Хотя стоит отметить, что в подавляющем большинстве случаев такие протоколы существуют только в качестве обходного пути из-за отсутствия параметризованных расширений.

Например, мы не можем сейчас говорить:

struct SomeGenericThing<T> {
    var value: T
}

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

}

Но введение протокола позволяет нам реализовать общий placeholder (s) как ассоциированный тип (ы), который мы можем затем использовать в ограничениях:

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

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

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

Поэтому, когда поддерживаются поддерживаемые параметры, мы сможем справиться с такими протоколами.