takasek
button.namespace.onTap ...
onTap should live on separated namespace to avoid potential conflict with other library.
e.g. button.rx.event
@Pircate had gave us the detailed implementation at #13 .
But lately I'd changed my mind of the comment above. I want to discuss about the motivation for introducing namespace.
In short, the namespace style is cool, but seems to resolve no problem. I don't hit upon any problem if ActionClosurable interfaces are even flat.
May Some beginners think that the extensions created by ActionClosurable are official interface?
But it's very popular to extend interface as you like.
ActionClosurable has simple interface and they strongly combines to the objects' responsibility.
button.onTap... seems natural for me.
In addition, extending init should be separated from the namespace.
For example,
UIBarButtonItem.init(title: "title", style: .plain, closure: ...)
cannot be
UIBarButtonItem.namespace.init(title: "title", style: .plain, closure: ...) .
I'm afraid that introducing a namespace might cause to more complex interface.
You can still create factory method like UIBarButtonItem.namespace.make(title: ...) though?
But it's very popular to extend interface as you like.
Library users can do that, but IMO library authors should avoid the namespace pollution as much as they could.
In addition ...
In short, the namespace style is cool, but seems to resolve no problem.
Just wanted to make it clear that my point was not about "cool or not" or "natural or not". I even prefer syntax to be as short as possible. (I'm also a golang fun.😎) But if I try to resolve problems in right way, then I would choose to separate namespace from UIKit or whatever frameworks Apple provides.
Of course this library is not 1000 or 10000 star library, I understand if you can keep it as is.👌 But if I have 1000+ star famous library, I would choose modularity than simplicity.
Thoughts? 🤔