GitHub 2014 GitHub Reactive Cocoa Developer Conference, 13 Jun 2014

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Modularity à la Taliban by Jon Sterling • GitHub Reactive Cocoa Developer Conference

Description

Software engineer Jon Sterling presents a tract on modular and compositional design for Objective-C projects at the 2014 Reactive Cocoa Developer Conference hosted by GitHub.

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
Google+: http://google.com/+github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

(Laughter) fantastisch.

A

Stop socializing. thank you. (laughter).

A

Alright, that looks about right., so there's only one more hurdle.

A

Between us talking about swift--(laughter), to give it one more minute.

A

Jon is going to come up and do a talk,, 15,, 20 minutes or so.

A

It's about modularity,, I guess,, presumably not too much about the taliban.

A

Probably more of the former than the latter, I'm guessing.

A

Then we will do the panel discussion. so without further ado, jon sterling.

A

B

Can people hear me?

B

(audience member)? Do you want help with the mic? (jon) yeah;? I don't know how to operate this thing. (audience member) machines.

B

yeah, machines;, it's too much for me.

A

Set that to a height, you are comfortable with. that looks good to me.

A

Just just testing you. good lord!.

A

I write software,, I swear.

B

Yeah,, alright well, hello, everybody.

B

So this ridiculous title, "modularity à la taliban".

B

Is sort of like the characterization that has been made at my workplace,.

B

Partly in jest,, partly in complaint, (laughter).

B

Of certain practices that I have adopted. today, I wanted to both defend that.

B

And also offer an alternative to some of the things that have been going. Around.

B

So (laughter), this is more how I feel about it.

B

In the reality-based community we have been doing modular design.

B

For about 25 years- and this is something that is not new.

B

It's not something we need to reinvent for cocoa.

B

It's very much a thing where there is a lot of prior art that we can draw from.

B

So I wanted to talk about two things, basically.

B

Start off with an extension to model view, view model,.

B

Which allows you to support pure view, models.

B

And then the other thing I wanted to talk about is.

B

How to properly separate your signatures from your structures.

B

In order to have a truly modular design, where, if you wanted to,, you could have your view models in one library.

B

And your view controllers in another one., then how to glue all of this together with rac or whatever compositional events framework, you're, using.

B

So my first realization was that mvvm is not enough.

B

The reason I say this is that if you look at typical mvvm code.

B

What usually ends up happening is the entire state of your view.

B

Is bound to mutable properties on your view, model.

B

We do this because we want the view model to know all of things. It needs to know,.

B

To be able to ask all the right questions, and then determine what it will do, next.

B

(Justin), can you give a brief overview of mvvm?

B

sure; mvvm--justin was asking a brief overview of that--.

B

Mvvm is where, instead of mvc, where you have a model,, a view and a view, controller,.

B

Mvvm is where you have a model,, a view and a view. Model.

B

Typically, the view includes the view, controller aspect., that's at least the tradition that I have been working. In.

B

The idea is that your network requests,, your I/o operations, occur in the view model.

B

And your view, controller exists to glue all that together into things.

B

That are presented in your view.

B

Let's have a look at an example of code that you might find in a readme or tutorial for mvvm-style work.

B

Your view has a text field.

B

And your view model has a mutable cell on it,.

B

A reference for whatever got put into the text field.

B

Let's say we are making an app where you type a message.

B

And then you hit submit and it does something..

B

Then you have a button on your view, and then we hook that up to an action on your view, model., then what happens is in the view model. We implement this action by reading.

B

From whatever the message was at the time, the button was pressed.

B

Then we enqueue some request.. I am using rac 3.0 here,.

B

Just because I have never used it before and I wanted to see what would happen.

B

But whatever you end up using,, you will presumably have signals,.

B

Bindings and some concept of a function.

B

So all of these things are reduced down to those, so it doesn't matter what version of rac I'm using. go. Ahead. (josh) this. Would this be a command in 2.0?.

B

So josh is asking if this would be a command in 2.0.

B

Indeed, rac action in 3 is the replacement to a command.

B

Then god knows what will happen to that in the next few weeks. (laughter).

B

But the idea is that when the button gets pushed, it sends an execute message.

B

To this action, and then it runs, and then the body of this block here is run.

B

So there's a few problems with this.: we failed to differentiate state from input.

B

I think that's actually a really important thing..

B

So what the user's typing in,- that's, not state,! That's input.!.

B

State should be the least information that you need in order to decide.

B

What you are going to do, next.? We don't need to know at all times what the user has typed in.

B

And if we do,, we should make those connections explicit, not by reading against a property,, a mutable property. On our view, model--.

B

Our view model is supposed to be the functional part of our program.

B

To have it be mutable ruins our ability to reason about state transitions.

B

So it turns out that we can take this interface, which was.

B

What the interface to the old hue model was, and we can change it, a little bit,.

B

And I'm sure many people have done this already in their view, models.

B

Simply get rid of that property and then make this action a proper function.

B

You will see these type annotations. its just a common--(laughter).

B

But the idea is that in this case; the action takes nothing in particular,.

B

That's it's input, and it yields something abstract.

B

That is something that we haven't specified in the interface..

B

Then here,. We change it to be an action that takes a string,, then yields something abstract. then we'll implement it a little bit differently.

B

In the view, controller, now we'll actually thread the user's text input into the action., because these signals are lazy. We can build up a wire program like this.

B

Where we say, "when, this happens, take one from the users input.".

B

As a result,, we don't have to actually talk to self anymore inside the body of this action;. We can just use its input.

B

Very much I see a view model as the thing which exposes.

B

A bunch of entry points at which the view can send it messages.

B

In this way, we don't need to write and then read;. We simply react.

B

That was (laughter) like #react.

B

So this is a minor change, but it actually.

B

Gives rise to a very different kind of design.

B

if we start from this very puritan idea of not having any mutable state exposed.

B

On our view, model,, then we will end up--.

B

When we do need to have actual state, we will end up--.

B

Let's say that the view model is accumulating all of the messages that were sent.. We need to have a way to do that.

B

And we need to do it purely. what I am doing is,, instead of having a state property,.

B

I bundle up all of the state that I could possibly care about, in my view, model, all of the things that I need in order to decide what to do next and all of the things I need in order to know what to show on my view, into a particular object-- for this program.

B

It is called messages state--, and then I expose it as a signal..

B

It is my responsibility, as implementer of this view, model to thread all of the information that comes in from the commands.

B

--The actions, and the actions are the only way to get the information.

B

Into the view model., it is my responsibility to thread all of those inputs into something that results in a coherent stream of states.

B

There are a number ways to do. That. here is our messages. State object.

B

It has this, so you can ask it: what messages have been sent,.

B

And then there is one basic version of it,, one that has no messages.

B

Then there is a way to create a new one that has another message in it.

B

We have simply exposed state transitions on this object and they are pure; they're immutable..

B

So these create new objects.. You are not actually changing.

B

The messages; that is read-only. not only read-only but also immutable.,.

B

This gets a little bit tricky,, but what we can end up doing is.

B

Having the body of this action-- remember, there was that underscore.

B

Which meant that the output of the action was abstract.?

B

This is what it actually is.. It is going to be--.

B

We will perform this action and then we will describe.

B

What that action did to the state.

B

That's modeled as a the function from state to state.

B

In this case,, the output of this action is going to be a function.

B

Which takes some arbitrary state and adds this message to it.

B

The idea is that somebody,, I guess me,.

B

Is going to have to thread all of those together into this coherent signal of states., then we can actually do that, like this.

B

You would simply scan across all of these transformations-- remember,. The output of the actions is bundled up in this results. Signal.

B

On the action or the command.

B

Starting with an empty state, and apply each state transition one after another, all we have to do is scan across that,.

B

To the result of the previous one., if you visualize with my hands,, it is like shoop shoop, shoop shoop., and that is sort of how it goes.

B

Then we expose that in the interface of our view, model.

B

Then all we have to do is-- like in our view,.

B

Let's say that we wanted to present a log of all the things that were done.

B

We simply have to observe the states of the view models..

B

Now we don't have to do any reading of properties anywhere;. It is all threaded.

B

Through very explicitly in such a way that we can reason about these things.

B

As pure functions on signals.

B

That's the purity aspect of this and the compositional aspect.

B

The other part that I wanted to talk about was how to use this, to make a truly modular design.

B

We've already had one big win,, which is our ability to separate two different things:.

B

The view model,, which is a notion of inputs towards state transitions,,.

B

From state, from the view, itself., that's already pretty modular.

B

But what I've realized is that there are aspects of each thing that the view controller doesn't need to know. About.

B

For instance, the view controller does not need to know how to create a view. Model.

B

view controllers should never be creating their own view. Models..

B

If you are doing that,, you are doing it wrong. (laughter).

B

What you should do is initialize your view, controller with a view model--.

B

And view models are only ever born from other view, models.

B

In that respect,, the view controller really only needs to have a basic idea.

B

Of what it requires from its view, model. the view controller also doesn't need.

B

To know anything about the model states, except what questions it can ask them.

B

it needs to know,. "What are the messages that have been sent?" but does not need to know how to create a new state based on a new message.

B

That stuff should be a secret.

B

The result of that is, we should be breaking these things up.

B

Into different signatures., then we can--at different entry points.

B

In our api, we can expose these objects.

B

Opaquely ascribed with a more restrictive signature.

B

The first signature is the state,, which is simply.

B

The ability to ask the question, "what are the messages?".

B

Then we have an object,, an implementation of this messages. State signature.

B

Which describes how to create states and how to transform.

B

One state into another state, and that's totally orthogonal from what it means.

B

To be a messages state., this is a secret that is known only by the view model,.

B

So you could put this implementation local inside the view model's file and no one would care.

B

Your view model has a similar issue,, where the only thing that anyone.

B

Except for the view, model itself needs to know about is,.

B

"What are its inputs and outputs, the actions and the signals?".

B

The view model itself-- the particular implementation you give it, how you initialize it, all of those things,.

B

That's the responsibility of the parent view, model.

B

Anyone should be able to construct their own version of it,.

B

So long as it can be ascribed to this signature, and as a result,.

B

The view controller knows nothing about the view model class, except that it adheres to this signature.

B

I would like to give an overview, or a demonstration of what it would look like to design something in this manner.. The other day I made.

B

A little tic-tac-toe app.

B

I am going to make this full-screen now.

B

Start from the beginning to describe how one would architect something like this,.

B

If that's helpful., the one exception to the idea that view models only ever create.

B

View models and nothing ever creates a view model, except for that is the appdelgate;. That's one place where we set the ball rolling.

B

We will make a view model here., it's that concrete class, and then we'll put it into a view controller,. But from then on the view controllers know nothing about view models and view models.

B

Can be considered entirely separately.

B

Let's have a look at our interfaces: quickly.

B

The view models interface is similar to the one we were dealing with. Before.

B

We have a way to play a tile.. We have a signal that tells.

B

When someone has won., then we have this little state machine, and this is that folding up of state transitions into states., a state machine here,, it is just.

B

Something that exposes signal states and a signal.

B

Of transition errors, in case you make a transition. That's not possible.,.

B

It doesn't matter how you implement this,, but in the view model itself.

B

We will actually go and implement it using an auxiliary object.

B

This state machine--we decided that our state transitions.

B

(Audience) (laughter) come on now.

B

Our state transitions are functions from a state to a signal of states.

B

Because when you play a tile, the computer responds by playing another tile.

B

What happens? Is, the state transition is,? I have an action and then two things: happen.

B

First, the state changes to show that I played this tile and then state changes.

B

To show the computer played this tile.

B

as a result, we need to compose functions of a to signal. A.

B

This kleislitransformstatemachine is a realization of that idea.

B

So here is this nasty scanning thing and there's auxiliary operator here which describes how to fold that crap up.

B

It's not really that important, because all the interface knows about is it has.

B

Some notion of what the states are.

B

We have another protocol for the state..

B

We describe what questions we can ask this state,.

B

What kind of concrete data are in there,, but we don't actually implement it.

B

It's the responsibility of the view model to provide an implementation..

B

The view model provides this particular implementation,, which has an empty state, and it has state transitions.

B

This is a function from south, the current state, to a signal of states.

B

That are brought on by this extra data, and we implement it in the usual way.

B

All of this stuff is tucked away. the view controller knows only about the questions. It can ask the view model, and thence. It knows only about the questions. It can ask the view. State.

B

Then we hook everything up.

B

In the view model, we construct the view., we bind the actions to the view model.

B

Note that we don't have some property.

B

We don't have a different action for every tile.. We put it as the input to the action, like "last tile played.". We don't do anything like that.

B

Because all it is, is a function from a to signal b.

B

We use post-composition to make that work..

B

Now we have a program and we can actually run it, god, willing.

B

Yeah,, it's a live, demo. (laughter).

B

Now we have a game, and it's not that great,, but the idea is that this was...

B

Nobody won., it was pure functional though.. Now we have the ability to reason about every aspect of our program, separate from every other aspect.

B

Of our program., we also have the ability to take our entire tower of view models and concrete view. State implementations, put them into one library,.

B

And have everything else in another library. in fact, there's something very special about that.

B

In the case of the app that I am working on at work,,.

B

It's pretty large,, but I can take it and have a static library.

B

Which represents all of the view models, and it would be entirely fine.

B

To create different views from it., that is, the classic mvvm promise actually realized.

B

On the other hand, it is all pure functional so that I can actually reason about it and understand what it does..

B

So that is why I consider this to be--.

B

Even if it looks like it takes more code,, it is the kind of code that I can just sit down and write.

B

I can just spit it out without having to think about it too. Much,.

B

Without having to think about, "have, I proved that when I access this,, this other thing hasn't changed?".

B

No, because I have a single, coherent pointer to the state,, because I am a function;.

B

I am not actually reading from self., it's not like. I have to worry about some self.state here,.

B

...Self.State there, and if anything changed, I am screwed.

B

No,, it is all functions.. That is why programming with functions is indeed a simpler way to do things,, even if sometimes it makes you write more code.

B

That's all that I wanted to show you,, but I am happy to answer you any questions you may have.

B

B

(Unknown), can you take.

B

Like right, here? (laughter), we'll save that for another time.

B

(Questioner) pragmatically,, it looks like avoiding capturing self strongly.

C

Is also ineffective in that you're not hitting reference cycles.

C

It's something I've been frustrated with in my own use of signals.

C

When I'm capturing self strongly, usually., I could be very [inaudible] somehow.

B

(Jon) you're right. (questioner), I mean, that seems like an orthogonal benefit.

C

I can't actually remember my question.

B

I'll try to repeat what rob was saying,, which is that another side benefit.

B

To this technique is that there are many cases where previously you would capture self in order to read at state,, or, god forbid,, even to write at state; good lord.

B

When you do that,, you end up having to avoid a retain cycle.

B

By making a strong reference on the outside of your block--.

B

Sorry,, a weak reference on the outside and a strong reference on your inside.

B

Even I get that wrong., I would say that when you're doing that,, it's a really good sign that there's a more compositional way to go about it,.

B

That will, on the one hand, be easier to reason, about, and, on the other hand, will make it. So you don't even have to worry about these retain cycles..

B

I would say that, if you're at risk for a retain cycle,, there's a really good chance that your design is not correct.

C

(Rob), I remembered my question. does that abstract to anything you're capturing, like closing over,, rather than taking as a parameter?.

B

Rob's question was, "does that abstract to anything, you're taking, you're capturing, as opposed to receiving as a parameter?".

B

I'm not really sure I understand. (rob) anything that you're closing over. That is like an __block reference,.

C

So something that might be updated rather than I'm just using some input, parameter.

B

I think you shouldn't do that, is what I would say.

B

Alright, good. thanks for listening. (applause).

A

Alright, we're going to take like ten minutes or whatever, to set up the panel up here with some comfy chairs,.

A

So you guys can go off and have drinks--is there still coffee?.

A

Or hang out here;, it doesn't matter,, but we're going to take about ten minutes.