5 ms·

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 unsubs

by jawngee 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.

by jawngee 11y ago

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 11y ago

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 11y ago
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 11y ago
  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.