Open Marcocanc opened 5 years ago
Thank you for your proposal @Marcocanc
As you described, Identifiable and Differentiable have semantically the same properties. However, Identifiable has OS restrictions, and I think there are few benefits to use it with breaking API. How about implementing such a simple extension?
public extension Differentiable where Self: Identifiable {
@inlinable
var differenceIdentifier: ID {
id
}
}
Thanks for the quick feedback. I understand that aligning the API might not be worth breaking existing code bases.
I have created a separate PR (#83) which introduces ContentIdentifiable
and removes its dependency from ContentEquatable
. Differentiable
is now a composed protocol.
This will allow to work with the protocols on a more granular level and avoid any breaking APIs.
Thanks @Marcocanc
The changes by #83 breaks the existing API, but agrees that it can be further clarified by separating identification and equality, so I'll allow this and include it in the next version 1.2.0.
Whether to change the naming differenceIdentifier
toid
will be discussed again when DifferenceKit grows to version 2.0.0.
Checklist
Description
Since the identity component of
Differentiable
is semantically identical to the newIdentifiable
protocol in Swift 5.1, I think it would be beneficial to align the two APIs.Motivation and Context
This allows us to easily conform to
Identifiable
as well asDifferentiable
through a single implementation.Proposed Solution
ContentEquatable
) and Identification (ContentIdentifiable
) component through the use of protocol composition forDifferentiable
ContentIdentifiable
to that ofIdentifiable
See #81 for implementation details