1) Allow two Cacheable
s of the same type to be compare
protocol Cacheable: Equatable {
//....//
func identifier() -> String
}
func ==<T : Cacheable>(lhs: T, rhs: T) -> Bool {
return lhs.identifier() == rhs.identifier()
}
Pros
This is the simplest solution.
Cons
You can only compare two Cacheable
objects of the same type. This means that code below will fail and in order to fix it you need to make Animal
conform to Cacheable
:
class Animal {
}
class Dog: Animal,Cacheable {
func identifier() -> String {
return "object"
}
}
class Cat: Animal,Cacheable {
func identifier() -> String {
return "object"
}
}
let a = Dog()
let b = Cat()
a == b //such comparison is not allowed
2) Allow Cacheable
s of any type to be compared
protocol Cacheable:Equatable {
//....//
func identifier() -> String
}
func ==<T:Cacheable>(lhs: T, rhs: T) -> Bool {
return lhs.identifier() == rhs.identifier()
}
func !=<T:Cacheable>(lhs: T, rhs: T) -> Bool {
return lhs.identifier() != rhs.identifier()
}
func ==<T:Cacheable, U:Cacheable>(lhs: T, rhs: U) -> Bool {
return lhs.identifier() == rhs.identifier()
}
func !=<T:Cacheable, U:Cacheable>(lhs: T, rhs: U) -> Bool {
return lhs.identifier() != rhs.identifier()
}
Pros
Removes limitations described above for solution 1. Now you can easily compare Dog
and Cat
.
Cons
- Implementation is longer. Actually I am not sure why specifying only
==
functions is not sufficient - this might be a bug with a compiler. Anyway, you have to provide the implementation for both ==
and !=
.
- In some cases the benefit of this implementation may also pose a problem as you are allowing the comparison between absolutely different objects and compiler is totally OK with it.
3) Without conforming to Equatable
protocol Cacheable {
//....//
func identifier() -> String
}
func ==(lhs: Cacheable, rhs: Cacheable) -> Bool {
return lhs.identifier() == rhs.identifier()
}
func !=(lhs: Cacheable, rhs: Cacheable) -> Bool {
return lhs.identifier() != rhs.identifier()
}
Pros
You can use Cacheable
as type without needing any generics. This introduces a whole new range of possibilities. For example:
let c:[Cacheable] = [Dog(),RaceCar()]
c[0] == c[1]
c[0] != c[1]
With solutions 1 and 2 such code would fail and you would have to use generics in your classes. However, with the latest implementation Cacheable
is treated as a type, so you are allowed to declare an array of type [Cacheable]
.
Cons
You no longer declare conformance to Equatable
so any functions which accept Equatable
parameters will not accept Cacheable
. Obviously, apart from ==
and !=
as we declared them for Cacheable
s.
If this is not a problem in your code I would actually prefer this solution. Being able to treat protocol as a type is super useful in many cases.
Binary operator '==' cannot be applied to two Cacheable operands
when trying to compare two object implementsCacheable
– Decoupage