4 ms·

The solution is to use more specific names. E.g. Cowboy.DrawGun(), Shape.DrawTo(canvas) Yes, sometimes this isn't an option when you want to satisfy the interf

The solution is to use more specific names. E.g. Cowboy.DrawGun(), Shape.DrawTo(canvas) Yes, sometimes this isn't an option when you want to satisfy the interface for two different libraries, but I've not seen this occur very often. More likely you're in control of one of the interfaces; so rename your method to be more descriptive.

pcwalton 12y ago
> Yes, sometimes this isn't an option when you want to satisfy the interface for two different libraries This is assumed in the description of the problem. Go has no solution for it. (Java doesn't either, but this is one of the things that C# got right over Java; it's unfortunate that Go has the same issue.)
- infogulch 12y ago
  You skipped the important part of my statement: > , but I've not seen this occur very often. Sure, it's a problem in theory. Whether it's a problem in practice is a different question. I'd be interested to see examples of this problem in the wild.
  - pcwalton 12y ago
    It comes up enough on Stack Overflow to indicate it's a real problem people are hitting: http://stackoverflow.com/questions/2598009/method-name-collision-in-interface-implementation-java http://stackoverflow.com/questions/2598009/method-name-colli... http://stackoverflow.com/questions/4033329/multiple-interfaces-with-same-method-names http://stackoverflow.com/questions/4033329/multiple-interfac... http://stackoverflow.com/questions/11343238/java-implementing-multiple-interfaces-with-same-method-and-different-return-ty http://stackoverflow.com/questions/11343238/java-implementin... http://stackoverflow.com/questions/17484325/implementing-multiple-interfaces-having-same-method http://stackoverflow.com/questions/17484325/implementing-mul... http://stackoverflow.com/questions/9863835/two-interfaces-with-same-method-signature-implemented-in-java-class http://stackoverflow.com/questions/9863835/two-interfaces-wi... http://stackoverflow.com/questions/19959371/calling-same-method-name-from-two-different-interface-java http://stackoverflow.com/questions/19959371/calling-same-met... http://stackoverflow.com/questions/14290902/multiple-interface-in-java-having-same-method-name-and-varable-name http://stackoverflow.com/questions/14290902/multiple-interfa... etc. etc. I got bored after the first page of Google results :)
    - tptacek 12y ago
      Which one of these links should I click to see someone having an actual practical problem based on this issue? Nobody is debating whether people notice the issue exists.
      - pcwalton 12y ago
        The very first one has a comment: > I encountered such a case where a legacy "Address" class implemented Person and Firm interfaces that had a getName() method simply returning a String from the data model. A new business requirement specified that the the Person.getName() return a String formatted as "Surname, Given names". After much discussion, the data was re-formated in the database instead. – belwood Further down someone hit a similar issue with the getString() method in some of the Android frameworks.
        infogulch 12y ago
        These examples seem to exemplify java's tendency towards design astronautics and the getter-and-setter-for-every-field pattern more than demonstrate the problem we're discussing here; I would find it very strange to see a `GetName() string` method on a go interface. Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either. Edit: And to take it a step further, I would say that since interfaces are Go's only resource for representing generic behavior, go developers are more mindful of the methods they add to interfaces, in both number and descriptiveness.
        pcwalton 12y ago
        > I would find it very strange to see a `GetName() string` method on a go interface. How else do you write a function that can take multiple types of structs, all of which have a Name field, and select that field? (Other than reflection.) I mean, there are a bunch of Go packages that have types with a method named precisely that: https://www.google.com/search?q=golang+"getname" https://www.google.com/search?q=golang+"getname" > Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either. Like in the Android case mentioned above? The Android system frameworks required a getString() method, while the MVVM library the commenter was using required an incompatible getString() method. Neither could be changed without a lot of headache.
  - rbetts 12y ago
    Real world example I hit a few weeks ago: I implemented a DB driver that had its own Next() method. Later I wanted to implement the SQL package interface. That interface contains Next() (http://golang.org/src/database/sql/sql.go?s=40568:40595#L1575 http://golang.org/src/database/sql/sql.go?s=40568:40595#L157...). Choices - break backwards compatibility and change the interface I control or convolute the type definitions to create a type specific to the database/sql interface. This limitation in combination with methods only being distinguished by name, not by parameters, turns out to be very annoying -- especially as interfaces profliferate.
    - EugeneOZ 12y ago
      Second option (separate interface) is obvious choice with duck-typing interfaces. edit: just to clarify: I don't like the idea "write more descriptive (over-verbose) method names" as solution for this problem.
      - pcwalton 12y ago
        > Second option (separate interface) is obvious choice with duck-typing interfaces. And this is called the "adapter pattern" in Java. It's also very annoying to have to use it when you hit it.
    - infogulch 12y ago
      Thanks for the example. Out of curiosity, what was the signature of your Next method? > I implemented a DB driver that had its own Next() method. Later I wanted to implement the SQL package interface. (Did you mean the database/sql/driver driver.Rows interface[1]? sql.Rows is a struct not an interface.) Just to be clear, you implemented a DB driver and then went to satisfy the driver interface? And this was after you already published it and would break backwards compatibility? > especially as interfaces proliferate. True. There will only be more interfaces over time. We'll want to keep them as small and descriptive as possible if we want the ecosystem to be sustainable. [1]: https://golang.org/pkg/database/sql/driver/#Rows https://golang.org/pkg/database/sql/driver/#Rows
    - NateDad 12y ago

pcwalton 12y ago

> Yes, sometimes this isn't an option when you want to satisfy the interface for two different libraries This is assumed in the description of the problem. Go has no solution for it. (Java doesn't either, but this is one of the things that C# got right over Java; it's unfortunate that Go has the same issue.)

infogulch 12y ago
You skipped the important part of my statement: > , but I've not seen this occur very often. Sure, it's a problem in theory. Whether it's a problem in practice is a different question. I'd be interested to see examples of this problem in the wild.
- pcwalton 12y ago
  It comes up enough on Stack Overflow to indicate it's a real problem people are hitting: http://stackoverflow.com/questions/2598009/method-name-collision-in-interface-implementation-java http://stackoverflow.com/questions/2598009/method-name-colli... http://stackoverflow.com/questions/4033329/multiple-interfaces-with-same-method-names http://stackoverflow.com/questions/4033329/multiple-interfac... http://stackoverflow.com/questions/11343238/java-implementing-multiple-interfaces-with-same-method-and-different-return-ty http://stackoverflow.com/questions/11343238/java-implementin... http://stackoverflow.com/questions/17484325/implementing-multiple-interfaces-having-same-method http://stackoverflow.com/questions/17484325/implementing-mul... http://stackoverflow.com/questions/9863835/two-interfaces-with-same-method-signature-implemented-in-java-class http://stackoverflow.com/questions/9863835/two-interfaces-wi... http://stackoverflow.com/questions/19959371/calling-same-method-name-from-two-different-interface-java http://stackoverflow.com/questions/19959371/calling-same-met... http://stackoverflow.com/questions/14290902/multiple-interface-in-java-having-same-method-name-and-varable-name http://stackoverflow.com/questions/14290902/multiple-interfa... etc. etc. I got bored after the first page of Google results :)
  - tptacek 12y ago
    Which one of these links should I click to see someone having an actual practical problem based on this issue? Nobody is debating whether people notice the issue exists.
    - pcwalton 12y ago
      The very first one has a comment: > I encountered such a case where a legacy "Address" class implemented Person and Firm interfaces that had a getName() method simply returning a String from the data model. A new business requirement specified that the the Person.getName() return a String formatted as "Surname, Given names". After much discussion, the data was re-formated in the database instead. – belwood Further down someone hit a similar issue with the getString() method in some of the Android frameworks.
      - infogulch 12y ago
        These examples seem to exemplify java's tendency towards design astronautics and the getter-and-setter-for-every-field pattern more than demonstrate the problem we're discussing here; I would find it very strange to see a `GetName() string` method on a go interface. Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either. Edit: And to take it a step further, I would say that since interfaces are Go's only resource for representing generic behavior, go developers are more mindful of the methods they add to interfaces, in both number and descriptiveness.
        pcwalton 12y ago
        > I would find it very strange to see a `GetName() string` method on a go interface. How else do you write a function that can take multiple types of structs, all of which have a Name field, and select that field? (Other than reflection.) I mean, there are a bunch of Go packages that have types with a method named precisely that: https://www.google.com/search?q=golang+"getname" https://www.google.com/search?q=golang+"getname" > Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either. Like in the Android case mentioned above? The Android system frameworks required a getString() method, while the MVVM library the commenter was using required an incompatible getString() method. Neither could be changed without a lot of headache.
- rbetts 12y ago
  Real world example I hit a few weeks ago: I implemented a DB driver that had its own Next() method. Later I wanted to implement the SQL package interface. That interface contains Next() (http://golang.org/src/database/sql/sql.go?s=40568:40595#L1575 http://golang.org/src/database/sql/sql.go?s=40568:40595#L157...). Choices - break backwards compatibility and change the interface I control or convolute the type definitions to create a type specific to the database/sql interface. This limitation in combination with methods only being distinguished by name, not by parameters, turns out to be very annoying -- especially as interfaces profliferate.
  - EugeneOZ 12y ago
    Second option (separate interface) is obvious choice with duck-typing interfaces. edit: just to clarify: I don't like the idea "write more descriptive (over-verbose) method names" as solution for this problem.
    - pcwalton 12y ago
      > Second option (separate interface) is obvious choice with duck-typing interfaces. And this is called the "adapter pattern" in Java. It's also very annoying to have to use it when you hit it.
  - infogulch 12y ago
    Thanks for the example. Out of curiosity, what was the signature of your Next method? > I implemented a DB driver that had its own Next() method. Later I wanted to implement the SQL package interface. (Did you mean the database/sql/driver driver.Rows interface[1]? sql.Rows is a struct not an interface.) Just to be clear, you implemented a DB driver and then went to satisfy the driver interface? And this was after you already published it and would break backwards compatibility? > especially as interfaces proliferate. True. There will only be more interfaces over time. We'll want to keep them as small and descriptive as possible if we want the ecosystem to be sustainable. [1]: https://golang.org/pkg/database/sql/driver/#Rows https://golang.org/pkg/database/sql/driver/#Rows
  - NateDad 12y ago