You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, some implementations of the LocalCollection interface rely on the "coincidence" that LocalCollection has the same naming convention / method signatures as for instance the AndroidCalendar from ical4android. Example:
LocalCollection : fun delete(): Boolean
AndroidCalendar : fun delete(): Boolean
So a sub-class of AndroidCalendar implements LocalCollection "automatically".
This is not documented, error-prone (because if for instance the return value of delete in ical4android changes, DAVx⁵ compilation breaks) and bad design.
Possible solution: Different naming, for instance deleteCollection() in the interface, and then in LocalCalendar:
Currently, some implementations of the
LocalCollection
interface rely on the "coincidence" thatLocalCollection
has the same naming convention / method signatures as for instance theAndroidCalendar
from ical4android. Example:LocalCollection
:fun delete(): Boolean
AndroidCalendar
:fun delete(): Boolean
So a sub-class of
AndroidCalendar
implementsLocalCollection
"automatically".This is not documented, error-prone (because if for instance the return value of
delete
in ical4android changes, DAVx⁵ compilation breaks) and bad design.Possible solution: Different naming, for instance
deleteCollection()
in the interface, and then inLocalCalendar
:etc.
The text was updated successfully, but these errors were encountered: