5 ms·

I see optional protocol methods as hints to the other developer that if you want to implement those methods, you can, the data is there. At least that is how I

by mapmap 8y ago

I see optional protocol methods as hints to the other developer that if you want to implement those methods, you can, the data is there. 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.

Razengan 8y ago
> 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.
- elpakal 8y ago
  Can't agree more with your disagreement. Also, in regards to documentation - Xcode's new(ish) support for Markdown makes adding code documentation almost an enjoyable experience.
- mapmap 8y ago
  Imagine a protocol for a download: 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?
  - Razengan 8y ago
    You'd present that as `ProgressReporting` or something, because other tasks besides a download would want to report their progress too, and indeed, the Foundation framework already has such a protocol [0]! 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/progressreporting https://developer.apple.com/documentation/foundation/progres... [1] https://developer.apple.com/documentation/foundation/progress https://developer.apple.com/documentation/foundation/progres...
elpakal 8y ago
>at the expense of outputting joyfully easy to follow code. 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.
- mapmap 8y ago
  You're right, memory management was a requirement in the early days and it created more cognitive load on the dev in exchange for not having to stall for garbage collection. But Objective-C has had automatic reference counting since around 2011. Retain and release aren't used anymore. 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.

by mapmap 8y ago

Razengan 8y ago

> 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.

elpakal 8y ago
Can't agree more with your disagreement. Also, in regards to documentation - Xcode's new(ish) support for Markdown makes adding code documentation almost an enjoyable experience.
mapmap 8y ago
Imagine a protocol for a download: 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?
- Razengan 8y ago
  You'd present that as `ProgressReporting` or something, because other tasks besides a download would want to report their progress too, and indeed, the Foundation framework already has such a protocol [0]! 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/progressreporting https://developer.apple.com/documentation/foundation/progres... [1] https://developer.apple.com/documentation/foundation/progress https://developer.apple.com/documentation/foundation/progres...

elpakal 8y ago

>at the expense of outputting joyfully easy to follow code. 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.

mapmap 8y ago
You're right, memory management was a requirement in the early days and it created more cognitive load on the dev in exchange for not having to stall for garbage collection. But Objective-C has had automatic reference counting since around 2011. Retain and release aren't used anymore. 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.