Iglistkit: Optional protocol conformance

Created on 12 Oct 2016  路  3Comments  路  Source: Instagram/IGListKit

Issue

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.

New issue checklist

  • [x] I have reviewed the README and documentation
  • [x] I have searched existing issues and this is not a duplicate

    General information

  • Library version(s): 1.0.0

  • iOS version(s):
  • Devices/Simulators affected:
  • Reproducible in the demo project? (Yes/No): Yes
  • Related issues:
question

Most helpful comment

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/

All 3 comments

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! 馃憤

Was this page helpful?
0 / 5 - 0 ratings