[swift-evolution] two protocols with the same method name

[Grzegorz Leszek]

Exactly there are two cases. I am working on a legacy project (aka
working effective with legacy code). It is written in objective-c.
There is a real life example where it was a problem. Of course it is
different language, but I have stared experimenting with swift and
found the same behavior. Object was conforming to 10 protocols. I was
just expecting different behavior of the class looking at the first
protocol.

I agree that it was easy to find a problem, yes it was different
language and yes it was bad naming and bad code. But we do not always
design every single class and protocol. Devs on the project have
different level of knowledge. Swift is new, so it is not a problem
now, but legacy code evolves after years and years. I think it would
be really great if Swift as a protocol oriented language could give a
hint that protocols declare the same requirements. Similar to warning
'unused variable'.

Brent ask a really good question: 'so we have to decide if "two
unrelated protocols declare the same requirement" is a strong enough
signal on its own to conclude that something's wrong'.
I believe it is strong enough.

Below is another example, similar to what I was struggling with:

protocol PrivatePhotos {
  func photos() -> String
}
protocol PublicPhotos {
  func photos() -> String
}
class Flickr: PublicPhotos  {
}
extension Flickr: PrivatePhotos {
  func photos() -> String {
    return "😡"
  }
}
class Newspaper {
  func printPaper(stock: PublicPhotos) {
    print(stock.photos())
  }
}
let stock: PublicPhotos = Flickr()
let dailyNews = Newspaper()
dailyNews.printPaper(stock) // private photos will be printed

Greg

2016-01-08 1:40 GMT+00:00 Jordan Rose <jordan_rose at apple.com>:
> Mm. There are two cases here:
>
> - Two protocols use the same method name for completely unrelated things.
> - Two protocols use the same method name for similar things.
>
> In the latter case, having one method satisfy both requirements is probably fine. In the former, there would definitely be a problem…but I have a hard time thinking of a type that should actually conform to two protocols that do completely different things and yet manage to use the same name for something. Do you have a real-life example where this has been a problem? Everything I can find online looks contrived.
>
> Jordan
>
>
>> On Jan 7, 2016, at 2:18, Grzegorz Leszek via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> I suggest compile warning if one classes/structs/enums implements
>> protocols with the same name.
>> It could lead to confusions, when methods of those protocols will mean
>> different things.
>> It will force to implement parent protocol with shared methods or
>> change method in one of the protocols.
>> Below is an example.
>> Regards,
>> Greg
>>
>> //💍
>> protocol A {
>>  var ring: String { get }
>> }
>>
>> //🔔
>> protocol B {
>>  var ring: String { get set }
>> }
>>
>> class X: A, B {
>>  var ring: String {
>>    get {
>>      return "💍"
>>    }
>>    set {
>>      self.ring = newValue
>>    }
>>  }
>> }
>> let x = X()
>> let somewhereInTheProject = "\(x.ring) the bell"
>> x.ring = "🔔" // ERROR!
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>