#associatedtype

original source : https://blog.bobthedeveloper.io/generic-protocols-with-associated-type-7e2b6e079ee2

참고내용

protocol Sequence<T> {    func generate() -> Generator<T> }

위와 같은 형식으로 generic protocol을 만들수 있지 않을까 생각할수 있지만 swift에서는 만들수 없다. 대신 associatedtype을 이용해야 한다. 

Introduction

You’ve started learning Protocols and you’ve got addicted to it. One day, you heard some words like associated type and type eraser. It seems rough and wild. I feel you. So, I wrote this tutorial for you. Let’s get started.

Goals

There are two objectives. First, learn how to create a generic protocol with associatedtype. Second, use where clauses for type constraints similar to that of generics.

Prerequisites

I consider this tutorial as somewhat intermediate-advanced. So, I expect you to be familiar with the topics below.

Intro to Generics, Intro to Protocol Oriented Programming, Closure, Typealias.

If you are not comfortable with the topics above, you might find Learn Swift with Bob useful.

p.s I’m going to be around a while. I plan to cover server-side Swift, RxSwift, Test driven, and all the good stuff. 😃

The Number One Rules

The Swift Programming Language is considered as type-safe. It means, the type must be defined before compiled.

Review

Before we dive into generic protocols, you should be familiar with the following code below.

struct GenericStruct<T> { var property: T? }

I could either explicitly state the type of T or let Swift infer based on the value.

let explictStruct = GenericStruct<Bool>() // T is Bool

let implicitStruct = GenericStruct(property: "Bob") // T is String

Keep in mind of the principle that every type must be defined.

Normal Protocol

First, to appreciate generic protocols, let’s look into your/my past. Let’s create a protocol that requires you to add property whose type is String.

Design Protocol

protocol NormalProtocol { var property: String { get set } }

Design Class and Conform

class NormalClass: NormalProtocol { var property: String = "Bob" }

Sounds good. However, NormalProtocol forces NormalClass to work with String. But, what if you want property to be Int or Bool?

It’s time to introduce Protocol Associated Types. 😎 (I should have a thug-life meme)

Introducing Protocol Associated Types

In generic protocols, to create something like <T> in generics, you need to add associatedtype.

protocol GenericProtocol { associatedtype myType var anyProperty: myType { get set } }

Associated type = type alias + generics

Now, anything that conforms to GenericProtocol must implement anyProperty. However, the type is not defined. Therefore, the class or struct that conforms to the protocol must define it either implicitly or explicitly.

First, let’s create a class SomeClass that conforms to GenericProtocol. We must define myType. Well, there are two ways to define as stated above.

Define Associated Type Implicitly

You may define myType based on the value associated with anyProperty.

class SomeClass: GenericProtocol { var anyProperty: myType = "Bob" }

Now, myType has been defined as String based on “Bob”. However, you can let Swift do more guessing as shown below.

class SomeClass: GenericProtocol { var anyProperty = "Bob" // myType is "String" }

Is everything okay with you? If so far so good, you can show me some love through ❤️.

Define Associated Type Explicitly

Well, you may also define the associated type, myType by calling typealias. What? Let’s take a look.

class SomeClass: GenericProtocol { typealias myType = String var anyProperty: myType = "Bob" }

If you want to define the associatedtype a.k.a myType, you may use typealias. Of course, it is not necessary since you may define myTypeimplicitly as we’ve seen.

So far, you’ve defined myType as String. Let’s create a struct that conforms to GenericProtocol but myType is Int instead.

struct SomeStruct: GenericProtocol { var anyProperty = 1996 }

You’ve implicitly stated that myType is Int based on the value of 1996.

If you hear Protocol Associated Types (PATs), it just means generic protocols.

Protocol Extension and Type Constraints

As you already know, Protocol extension is amazing because it provides default implementations without having to define required methods and properties. Let’s review.

Design Extension

extension GenericProtocol { static func introduce() {  print("I'm Bob") } }

Anything that adopts GenericProtocol now contains this magic.

SomeClass.introduce() // I'm Bob SomeStruct.introduce() // I'm Bob

original source : https://schani.wordpress.com/2014/06/03/playing-with-swift/

이 예시에서 associatedtype을 위해 protocol 정의부분 안에서 사용되고 있는 typealias 는 deprecated 되었음을 인지할것

Playing with Swift

I really like what we’ve seen so far of Swift, Apple’s new programming language. For starters, I was happy to learn that references cannot be nil[1], and integer arithmetic is checked by default[2].

Let’s look at how Swift deals with sequences, and learn a little bit about generics on the way. Arrays, for example, are sequences, so you can iterate over them with a for loop:

for x in [1,2,3] {    println(x) }

Lots of other types are sequences, too, like strings, dictionaries and ranges. What makes them sequences is that they all implement the Sequence protocol:

protocol Sequence {    typealias GeneratorType : Generator    func generate() -> GeneratorType }

I’m not sure why Swift elects to do generic protocols via typealias instead of just having the protocol take type arguments, like C# does, which might look something like this:

protocol Sequence<T> {    func generate() -> Generator<T> }

Whatever the reason might be, we can see that a sequence can generate a Generator, which is defined as follows:

protocol Generator {    typealias Element    func next() -> Element? }

Generators have a next method which returns either the next element in the sequence, or nil, when the end has been reached. The for loop from above is probably mostly equivalent to

var gen = [1,2,3].generate() while let x = gen.next() {    println(x) }

The equivalent of Sequence and Generator in C# are IEnumerable and IEnumerator.

The map function takes a sequence and a function, returning a new sequence containing the results of applying the function to the elements of the given sequence. For example:

for x in map([1,2,3], {i in i*2}) {    println(x) }

produces

2 4 6

It’s important to realize that the sequence which map returns is not necessarily of the same type as the one it is passed:

println([1,2,3]) println(map([1,2,3], {i in i*2}))

prints

[1, 2, 3] VSs17MapCollectionView (has 2 children)

Also, sequences can generate their elements lazily:

var seq = map([1,2,3], { (i: Int) -> Int in    println("processing " + String(i))    return i*2    }) var gen = seq.generate() println(gen.next())

prints

processing 1 2

Let’s write a function that takes a sequence and returns an array containing all the sequence’s elements!

First we need to figure out the type of this function. It turns out that this doesn’t work:

func toArray (seq: Sequence) -> seq.GeneratorType.Element[]

The compiler complains that seq is an undeclared type. This doesn’t work, either:

func toArray (seq: Sequence) -> Sequence.GeneratorType.Element[]

Here the complaint is that Sequence.GeneratorType is ambiguous. That’s because we can’t tell the compiler that the two Sequence types are the same. Maybe we can use generics to solve the problem:

func toArray<S:Sequence> (seq: S) -> S.GeneratorType.Element[] {    var arr = S.GeneratorType.Element[]()    ...    return arr }

Swift is now happy with the type of the function, but unfortunately it doesn’t let us instantiate the array. Instead it thinks we’re trying to subscribe S.GeneratorType.Element, which isn’t possible, because it’s a type and not a value. As far as I can tell, the only way to get around this problem is to introduce a second generic argument, which we can force to the correct type via a where clause:

func toArray<S : Sequence,             T where T == S.GeneratorType.Element>        (seq : S) -> T[] {    var arr = T[]()    for x in seq {        arr.append(x)    }    return arr } println(toArray(map([1,2,3], {x in x*2})))

And there we have it:

original source : https://www.natashatherobot.com/swift-what-are-protocols-with-associated-types/

I recently gave a talk about Protocols with Associated Types (PATs) – I was worried that my audience would already know everything about PATs, but turns out the opposite is true.

Many didn’t know what PATs were – which I should have anticipated in hindsight, since it took me a while to learn about them myself. So I wanted to explain them right here, especially since they are challenging to understand and there aren’t that many great explanations that I’ve found.

The best explanation that really helped me was by Gwendolyn Weston at the try! Swift conference in Tokyo (video here), so the example is inspired by her talk. There will be Pokemon…

Before PATs

I’m currently Level 9 in Pokemon Go, and I learned (thanks to my personal trainer @ayanonagon) that all Pokemon have some common traits, such as the power to attack.

Coming from Objective-C or other object-oriented languages, it might be tempting to have a Pokemon subclass for all the common functionality. Since each Pokemon attacks with a different power – lightning or water or fire, etc – we can use the power of Generics in our subclass:

// we have to ensure that the generic Power // has an init function protocol Initializable {    init() }

// Pokemon subclass // Each Pokemon has a different Power, // so Power is a generic class Pokemon<Power: Initializable> {

   func attack() -> Power {        return Power()    } }

At this point, we would have different Powers modeled:

// power types

struct 🌧: Initializable { // implementation }

struct 🌩: Initializable { // implementation }

struct 🔥: Initializable { // implementation }

Now, other Pokemon can subclass from our base Pokemon class, and they will automatically have the attack function!

class Pikachu: Pokemon<🌩> {} class Vaporeon: Pokemon<🌧> {}

let pikachu = Pikachu() pikachu.attack() // 🌩

let vaporeon = Vaporeon() vaporeon.attack() // 🌧

The problem here is that we’re subclassing. If you’ve watched Dave Abrahams’ WWDC talk on Protocol-Oriented Programming in Swift, you should be seeing the face of Crusty in your head right now…

The problem with subclassing is that while it starts out with great intentions, eventually things get a lot messier as exceptions arise (e.g. Pokemon Eggs can’t attack). I highly recommend reading Matthijs Hollemans’s Mixins and Traits in Swift 2.0 to understand this more.

After all, as Dave Abrahams stated, Swift is a Protocol-Oriented Language, so we need to change our Object-Oriented mindset…

Hello, PATs

Instead of subclassing, let’s do the same thing with PATs! Instead of subclassing all the things, we can create a Protocol that focuses on the Pokemon’s ability to attack. Remember, since each Pokemon has a different Power, we need to make that a Generic:

protocol PowerTrait {    // That's it! An Associated Type is just    // different syntax for Generics in protocols    associatedtype Power: Initializable

   func attack() -> Power }

extension PowerTrait {    // with protocol extensions,    // we can now have a default attack function    func attack() -> Power {        return Power()    } }

Now, any Pokemon that conforms to the PowerTrait protocols will have the attack functionality no subclassing necessary!

struct Pikachu: PowerTrait {    // since we're using the default attack functionality    // we have to specify the type of the associated type    // just like we did when subclassing with a generic    // * note that this is still called typealias, but will be changed    // to associatedtype in future versions of Swift    associatedtype Power = 🌩 } let pikachu = Pikachu() pikachu.attack() //🌩

struct Vaporeon: PowerTrait {    // when the attack function is overwritten    // 🌧 is inferred as the associated type    // based on the method signature    func attack() -> 🌧 {        // custom attack logic        return 🌧()    } } let vaporeon = Vaporeon() vaporeon.attack() //🌧

Conclusion

That’s it! A protocol with associated type is just a fancy term to a protocol that has generics in it. By using PATs (and protocols in general), we have a powerful tool that promotes really nice composition in favor of messy inheritance.

To learn more about the limitations of PATs and go deeper, I highly recommend Alexis Gallagher’s talk here.