Comments (4)
I've gone down the default implementation route before, and I believe it is more hurtful than helpful long-term since it removes any compile-time checking that you've implemented the methods you think you have (when migrating Swift versions, API versions, or just maintaining a large codebase with many developers this compile-time check is essential).
Providing default implementations of methods that have return values also makes me guess intent of the consumer, makes adoption more complex (no longer does the compiler tell you what you need to implement), and distributes the logic adoptees need to care about across packages. Today, consumers just need to be concerned with the protocols they implement (consumers shouldn't care about what SuperDelegate is doing behind the scenes). If we provided default implementations, now consumers need to check what SuperDelegate has implemented & how.
I'm curious what methods feel like boilerplate to you. Giving me a sense of where the API feels verbose will help me address the concern you're raising 🙂
from superdelegate.
While I sympathize that you don't always need every method, optional protocol methods can lead to a world of hurt and aren't very swift-y (would require our protocols to inherit from NSObjectProtocol
) . Having required protocols means that the compiler can enforce that you've properly implemented what you intended to implement, and enforces a stricter API.
I find the safety-blanket provided by required implementations strongly outweighs the value of optional implementations. That said, maybe our protocols are requiring too much? Are there specific protocols we have that you find you tend to only use part of? Maybe the better answer would be for us to split those protocols up into smaller bits.
from superdelegate.
Splitting up could be a solid idea. I do not really have a strong opinion on that. I am very open to new ideas. Here is something which came to my mind this morning: I think the most possible Swifty way would be to provide default implementations for the protocols via extensions. Let's just pick StateRestorationCapable
for the example:
protocol StateRestorationCapable: ApplicationLaunched {
func shouldSaveApplicationState(using coder: NSCoder) -> Bool
func shouldRestoreApplicationState(using coder: NSCoder) -> Bool
func willEncodeRestorableState(using coder: NSCoder)
func didDecodeRestorableState(using coder: NSCoder)
func viewControllerWithRestorationIdentifierPath(identifierComponents: [Any], coder: NSCoder) -> UIViewController?
}
A default implementation could look like the following:
extension StateRestorationCapable {
func shouldSaveApplicationState(using coder: NSCoder) -> Bool {
return true
}
}
If you are in need of one specific protocol function, you can just override the extension or implement the protocol requirement.
As a quick demonstration (you are pleased to create a playground from scratch):
protocol StateRestorationCapable {
func shouldSaveApplicationState() -> Bool
func shouldRestoreApplicationState() -> Bool
}
extension StateRestorationCapable {
func shouldSaveApplicationState() -> Bool {
return true
}
func shouldRestoreApplicationState() -> Bool {
return true
}
}
class Test1: StateRestorationCapable {
}
class Test2: StateRestorationCapable {
func shouldRestoreApplicationState() -> Bool {
return false
}
}
print(Test1().shouldRestoreApplicationState())
print(Test2().shouldRestoreApplicationState())
I am with you when talking about what does feel Swifty ❤️ and what does not. But as it is nowadays very simple to look up the API documentation (and of course you really should do beforehand you are consuming it) I think reducing boilerplate is essential.
I think both approaches:
- i) splitting up
- ii) providing default implementations
are solid.
In my eyes, I would go with ii) as splitting up may cause a protocol soup and with default implementations we also could add some debugging output, like print("HINT: shouldRestoreApplicationState uses default implementation")
.
from superdelegate.
Never thought of a very large codebase with multiple maintainers. In my small world the default implementation may work out, but I see and acknowledge your point. Then splitting up would be the way to go.
Concerning boilerplate, maybe I shot myself in the foot. I had this problem especially using my own LifeCycleAware
implementation :) The moment you are realizing: it wasn't the best idea.
from superdelegate.
Related Issues (15)
- Tapping on a notification in Notification Center while app in foreground but inactive doesn't return .UserTappedToBringAppToForeground HOT 8
- Warning: Unable to create restoration in progress marker file HOT 4
- setup(mainWindow:) shouldn't set UIWindow's bounds on iOS9+ HOT 5
- App Delegate Life Cycle Protocol HOT 6
- Emphasize UIApplicationDelegate protocol requirements HOT 1
- SuperDelegate should not contain test helpers HOT 4
- Add support for being launched with only a source application
- Add LaunchItem for unknown launch options
- [1.0] Adopt UIUserNotification* API from iOS 10 SDK HOT 7
- Swift 4.2 support HOT 2
- Should not need to re-request UserNotification permissions on every WillEnterForeground HOT 2
- RemoteNotification should search for values in "aps" dictionary instead of top level. HOT 9
- Add optional method that has unedited launchOptions? HOT 2
- Build fails when integrating through Cocoapods HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from superdelegate.