The singleton pattern is encouraged, but doesn't support multiple callbacks

[colinta]

Since callbacks only stores one closure of each event type, multiple controllers that use Typist.shared will "fight" over who receives notifications.

class ControllerOne: UIViewController {
  override func viewDidLoad() {
    Typist.shared.on(event: .willShow) { _ in print("will show from one") }
  }
}

class ControllerTwo: UIViewController {
  override func viewDidLoad() {
    Typist.shared.on(event: .willShow) { _ in print("will show from two") }
  }
}

If both of these controllers are loaded, only the second controller will get the notifications.

Easy fix: remove the singleton, and have each controller retain its own Typist instance.

[MichalAlgor]

The current solution let you do that. You don't have to use shared singleton, just do as you proposed. Use different instances of Typist in your controllers.

[colinta]

Right, but encouraging the use of the singleton will lead to bugs. The "correct use" should be the one that is documented in the README. As it is now, the README doesn't mention this bug/limitation. Your package was included in "little bites of cocoa" and the author there also didn't point out that using the singleton is a bad idea, probably because it's not mentioned in the README.

[totocaster]

Hey Colin, what you described is true and I though that's was obvious, thus the comment in README about singleton vs new instance. Reason there is an option to use singleton at all is to give quick access to instance without having a dedicated class property (Typist().on(... would deallocate immediately.) Having said that, your argument is totally valid. I'll reword docs and mention this limitation when working with singleton. —Thank you!

[totocaster]

Updated README. This is not final decision though, I'll think more about singleton usage and it's benefits vs confusion factor.