Where possible, protocols should allow for optional conformance to avoid having empty implementations.
This is seen in the example app as:
func listAdapter(_ listAdapter: IGListAdapter, willDisplay sectionController: IGListSectionController) {}
func listAdapter(_ listAdapter: IGListAdapter, willDisplay sectionController: IGListSectionController, cell: UICollectionViewCell, at index: Int) {}
func listAdapter(_ listAdapter: IGListAdapter, didEndDisplaying sectionController: IGListSectionController) {}
func listAdapter(_ listAdapter: IGListAdapter, didEndDisplaying sectionController: IGListSectionController, cell: UICollectionViewCell, at index: Int) {}
or
func didSelectItem(at index: Int) {}
Seems this is partially complicated by ObjC to Swift bridging that creates ambiguous method / argument namings.
README and documentation[x] I have searched existing issues and this is not a duplicate
Library version(s): 1.0.0
Thanks @iwasrobbed ! 馃槃
This design is intentional.
We consider using Using @optional protocol methods are to be bad practice in Objective-C (not safe, no static compiler checks, etc.) and as you noted, this makes bridging to Swift painful.
This is why we've opted to breakup protocols into multiple different ones to mitigate "do nothing" methods as much as possible.
Ash Furrow has a great post about this: https://ashfurrow.com/blog/protocols-and-swift/
Thanks @jessesquires. Once you all convert the protocols over to Swift one day, you may want to consider using default protocol implementations so it will avoid the empty calls (as well as the optionality)
Definitely! 馃憤
Most helpful comment
Thanks @iwasrobbed ! 馃槃
This design is intentional.
We consider using
Using@optionalprotocol methodsareto be bad practice in Objective-C (not safe, no static compiler checks, etc.) and as you noted, this makes bridging to Swift painful.This is why we've opted to breakup protocols into multiple different ones to mitigate "do nothing" methods as much as possible.
Ash Furrow has a great post about this: https://ashfurrow.com/blog/protocols-and-swift/