This workshop will be retired on May 31, 2020.
Composing Classes and Protocols3:26 with Pasan Premaratne
In this video let's talk about a feature that allows Swift to represent existentials of classes and subtypes which conform to protocols.
Swift 4 brings a much needed change to how we can represent the identity 0:00 of our types. 0:04 This is an easy change to understand, 0:05 let's say we have a protocol that defines an interface for delivering events. 0:08 protocol, we'll call this EventDeliverable 0:13 We'll be keeping the implementations of any types here empty, 0:22 since they don't really add anything to the understanding of this example. 0:24 Next we have a series of classes, so we have a view, 0:28 we have a notification, and notification are events, 0:33 and conform to EventDeliverable. 0:38 We then have two subclasses of the View, so first one will be a button. 0:42 Now a button can also deliver an event, so 0:50 we're going to make it conform to EventDeliverable. 0:52 And then, finally, we have a label, and a label is a view, and that's it. 0:57 What if we wanted to write a method that only accepted views that conformed to 1:03 EventDeliverable as valid arguments? 1:08 In Swift 3, we could compose two protocols together using the ampersand operator. 1:10 But if we wanted to restrict types to a class that conformed to a protocol, 1:16 the only way we could do so was with generics and generic constraints. 1:20 In Swift 4, this is much easier, using the & operator, 1:24 we can now compose classes and protocols. 1:29 So a simple example looks like this, so triggerEvent, we'll write a function here. 1:31 And this takes an eventDeliverableView, and here we'll say this has to be a view. 1:37 So the argument provided to this function needs to be a view, or 1:43 a subclass of a view, and it has to conform to EventDeliverable. 1:47 Inside the function, 1:54 you now have access to the interface defined by EventDeliverable, 1:55 as well as any public methods, properties, or subscripts exposed by the View type. 2:00 So if we were to call triggerEvent, and 2:06 we tried to pass in a Button instance, that works. 2:09 But if we were to do the same thing and pass in an instance of Label, 2:14 that should fail, and similarly, Notifications would fail as well. 2:18 So over here, the error says, 2:26 argument type Label does not conform to expected type View & EventDeliverable. 2:28 As I just mentioned, we could achieve this in Swift 3 using genetics, but 2:34 there's added flexibility with the new syntax. 2:38 For example, we can create a collection that only contains types that 2:41 are subclasses of View, and conform to EventDeliverable. 2:45 So we'll say, let eventViews, and the type is View & 2:49 EventDeliverable, and we'll just put an empty right here. 2:53 Now when we iterate through eventViews, so for eventView in eventViews, 2:59 using a for loop, again, we are guaranteed interfaces of both types. 3:04 It's a change that allows for a much more expressive type system. 3:10 The changes described here can be found in more detail in proposal SEO156, 3:15 classes and subtype existentials, which is linked to in the notes section. 3:19
You need to sign up for Treehouse in order to download course files.Sign up