
An Observable Pattern Implementation in Swift - jaxondu
http://colindrake.me/2015/10/01/an-observable-pattern-implementation-in-swift/
======
melling
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](http://www.h4labs.com/dev/ios/swift.html)

The raw data is on GitHub:
[https://github.com/melling/SwiftResources](https://github.com/melling/SwiftResources)

------
autoreleasepool
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.

------
Tloewald
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.

~~~
jawngee
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.

~~~
Tloewald
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).

~~~
jawngee
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.

~~~
Tloewald
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.

------
gorena
RAC does all of this and more:

[https://github.com/ReactiveCocoa/ReactiveCocoa/blob/master/R...](https://github.com/ReactiveCocoa/ReactiveCocoa/blob/master/ReactiveCocoa/Swift/Property.swift)

