An Observable Pattern Implementation in Swift | Hacker News Reader

An Observable Pattern Implementation in Swift

colindrake.me

10 pointsjaxondu8 comments

Just a quick note for anyone learning Swift, my collection of Swift Resources just past 2000 urls: http://www.h4labs.com/dev/ios/swift.html

The raw data is on GitHub: https://github.com/melling/SwiftResources

Lately, I've seen a lot of people claiming that the Objective-C runtime is something worth avoiding. I don't find this to be true. It is highly optimized, with hand written assembly, and it is very fast at what it does. Not to mention Apple's entire framework is build around it.

The new trend favoring Swift value types often leads to reinventing the wheel for the sake of premature optimization.

I'm curious as to why the observable needs a reference to the subscribing object at all. The subscriber knows who it is. (Similarly, why does the update callback need to pass the old value?)l If the subscriber didn't keep a copy of the old value then presumably it doesn't care.

I'm guessing the new/old value is a carry over from how KVO works and could be useful for a few cases.

Holding a ref to the subscriber so that it can be unsubscribed.

I think it violates my ideas about good APIs which should transfer only the smallest amount of information necessary to do the job. When I subscribe to something all I am asking is that I be notified when a thing changes and to be told what the change is. I should be able to do this outside of an object if I want to.

So a subscription needs a method to call when the value changes. And the method needs to pass the new value.

Being unsubscribed isn't enough because if I really care about the object I need to know when it goes away, not just be magically unsubscribed from it and continuing in my own little fantasy land where the object still exists.

Edit:

Continuing the thought, I think the model needs two protocols -- a publisher and a subscriber. The subscriber automatically cancels subscriptions when it goes away and the publisher automatically cancels subscriptions when it goes away. The information passed in a given case is simply what object and property I am subscribing to (since, as a subscriber I already know who I am, and the information can be encapsulated without being passed).

I'm not sure what you are proposing is a good API design though. There are plenty of times using KVO where you only want to subscribe for a certain transition of state, well within the lifecycle of either objects.

And I'm not even sure how you'd implement what you are talking about without tracking your subscribers. How does it automatically go away? Weak references with the subscriber implementing a protocol? It's now gotten more complicated than what the original author has proposed. imho.

I'm proposing something slightly more complex under the hood to be sure. But the API is simpler. And the point of APIs is to eliminate implementation details from the interface.

RAC does all of this and more:

https://github.com/ReactiveCocoa/ReactiveCocoa/blob/master/R...

Reply on news.ycombinator.com