A modest proposal for optional methods in Swift protocols
cocoasamurai.blogspot.com
cocoasamurai.blogspot.com
I believe Chris Lattner said something along the lines as well back in Swift Evolution proposal: "They are non-sensical - how can something be a requirement and be optional? :)"
Source - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
At least that is how I use them in Obj-C, which is proving to me to be the more flexible alternative to Swift (despite the hype that Swift is amazing in every use case).
This roots back to one of my main problems with Swift: it doesn't adequately support the in-code conversation between developers. For example: no header files to quickly digest key object interfaces and concepts. The language feels like it is optimized to solve compiler problems and point out null value bugs at the expense of outputting joyfully easy to follow code.
I disagree.
How is "These are the requirements, oh but some of these are not really required." easy to follow?
Swift does a great job of making it easy to make sense of code at the point of use, without having to keep referring back to the definitions of things.
A protocol is a set of requirements. When I see a type adopting a protocol, I know that it must fulfill those requirements. Done. I don't need to check if any of the requirements were optional and I don't need to check if the conforming type implements those optional requirements.
If you need optional requirements (an oxymoron), then just break it into ProtocolA and ProtocolB, using protocol inheritance if needed. That's what the Standard Library does (e.g. with `Collection` and `MutableCollection` etc.) and it works great.
Also, at runtime, I just need to see if `type is ProtocolA` or `type is ProtocolB`. How would you check for the implementation of optional methods within a single protocol, without basically reinventing Objective-C?
Finally, good riddance to header files! May they forever remain entombed along with the semicolons. There are other ways to see the overview of a type. Xcode's Symbol Navigator for one, or the Interface Assistant Editor, or you can put in about the same effort as writing a header file to write good documentation.
Required 1. Download finishes 2. Download fails
Optional 3. Download progress (for updating a progress bar)
This seems legit to me. Would one really want the added overhead of having to implement 3 as a separate protocol?
In your first comment you seem to value the ability to "quickly digest key object interfaces and concepts" but you balk at the added clarity afforded by separating different behaviors into distinct protocols?
If by "overhead" you mean a cost to performance, worrying about it at that level falls under premature optimization, until you're certain that the extra protocol noticeably harms performance.
If you really insist on having a single protocol, then make `progress` an optional computed property.
[0] https://developer.apple.com/documentation/foundation/progres...
[1] https://developer.apple.com/documentation/foundation/progres...
You're not really suggesting here that Objective C is easier to follow than Swift are you? ^*(retain, release, etc) [] ;. The language is filled with characters that make it a challenge to read imo.
I have talked to many people who have had a hard time getting past the square brackets - I did at first too. But now I think of them as book ends around the work. In my opinion, they are clearer to divide actions with. They can of course be abused with many layers of [[[]]], but so can the optional unwrapping code golf one-liners I see written in Swift.
And I agree with you, block syntax is terribly hard to remember. I still copy paste or use typedefs. But I love using blocks – they've done so much for readability of asynchronous code. The language really has come a long way since the first iPhone.
The phrase "A Modest Proposal" is generally associated with the essay's author, Jonathan Swift. By combining that phrase in a literal sense ("I'm suggesting something new about how to handle option methods") with the name of a programming language which coincidentally is the surname of the author, it leads to a clever connection.
It would be like an article called, "Do not cast your Perls before swine" about dynamic casting which also is a play on the common phrase, "Do not cast your pearls before swine." [Yeah, that example kind of sucks but it was the first thing that popped into my head.]
You're right, it would be like that hypothetical article if you both made up a clever title involving perl and casting and the modest proposal thing was particularly clever. But it's not, so that hypothetical rather begs the question.