Swift property observer in protocol extension?

Question

Consider the following:

protocol ViewControllable: class {
  typealias VM: ViewModellable
  var vm: VM! { get }
  func bind()
}

extension ViewControllable {
  var vm: VM! {
    didSet {
      bind()
    }
  }
}

I'm trying to observe vm property and call bind whenever it is injected. But this doesn't compile with error saying:

Extensions may not contain stored properties

which makes sense since protocol cannot enforce properties to be stored or computed.

Is this possible to accomplish without introducing class inheritance?

In other words, Can I observe the change of a property inside protocol extension?

note that you can indeed do this very easily, *if you use an associated property*. Here's a recent post from me on exactly how to make an associated property: [example](http://stackoverflow.com/documentation/swift/1085/associated-objects/27656/property-in-a-protocol-extension-achieved-using-associated-object#t=20170128181236289743) That is quite fresh as of writing this, so hopefully it's pretty stable. — Fattie, Jan 28 '17 at 18:14
Regarding this question, a perfect example of where you could use this is the example used in this QA: http://stackoverflow.com/questions/41910120/in-swift3-combine-respondsto-and-calling-in-one-fell-swoop — Fattie, Jan 28 '17 at 18:23
@Fattie can you please fix that link. I currently can't view your post or example. — TMin, Jan 31 '19 at 20:23
Ah you mean the first link ! Note that SO ***closed down*** the "documentation" feature. Unfortunately, the example is gone forever. Sorry ! — Fattie, Jan 31 '19 at 20:25
Here it is, I think: https://web.archive.org/web/20170221052848/http://stackoverflow.com/documentation/swift/1085/associated-objects/27656/property-in-a-protocol-extension-achieved-using-associated-object — koen, Oct 06 '19 at 18:56

score 38 · Accepted Answer · answered Nov 23 '15 at 04:27

38

No, this is explicitly disallowed. See Extension: Computed Properties:

Extensions can add new computed properties, but they cannot add stored properties, or add property observers to existing properties.

Keep in mind that if this were legal, it would add some non-trivial confusion about order of execution. Imagine there were several extensions that added didSet, and the actual implementation also had a didSet. What order should they run in? This doesn't mean it's impossible to implement, but it could be somewhat surprising if we had it.

answered Nov 23 '15 at 04:27

Rob Napier

286,113
34
456
610

3

Thanks for the clarification. But I beg to disagree about the **confusion** that it may bring with it. Many other programming languages deal with this kind of diamond problem by either making them explicit with compile error or inferring from the order of declarations. Scala, for example, when in conflicts, give priority to whichever `trait` (`protocol`) that is declared after in class `extends` (`:`). – Daniel Shin Nov 23 '15 at 04:50
> "What order should they run in?" really? I naturally wanted to have this functionality. Eg. You have a new customer. The only piece of information you care about is his unique identifier. You set the identifier. Up on setting this identifier, protocol methods go and fetch all the information about the customer that we need. Not hard to execute code in correct order I want the code to take care of the rest, not having to care about calling all of the functions manually. As it is now, it feels uncomfortable to work with protocols and extensions without this – Fero Sep 15 '16 at 10:25
1

uuuh heartache :( – Ishaan Sejwal Nov 13 '16 at 12:15
@Ferologics and others - you can indeed do this, if you're willing to use an associated property. See my comment under the question. – Fattie Jan 28 '17 at 18:15

Swift property observer in protocol extension?

1 Answers1

Linked