6 ms·

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 practic

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.
        infogulch 12y ago
        Funny, the first link in your google search is slides for a presentation called "Go for Javaneros". The presentation takes a java program, finds a problem with it and fixes the problem in both java and Go. Go's solution starts with a `Name() string` method, but then he drops the method completely in favor of a public Name field instead. Other links in that google search are clear examples of a naive java-to-go translation with half a dozen `GetX() X` methods. > 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? That presentation that you linked to says to use struct embedding aka composition. And if you don't want to do that then I'd say you're "probably" framing the problem wrong, but we really need a more concrete example to discuss this further otherwise we'll just be talking past each other.
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

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.
      - infogulch 12y ago
        Funny, the first link in your google search is slides for a presentation called "Go for Javaneros". The presentation takes a java program, finds a problem with it and fixes the problem in both java and Go. Go's solution starts with a `Name() string` method, but then he drops the method completely in favor of a public Name field instead. Other links in that google search are clear examples of a naive java-to-go translation with half a dozen `GetX() X` methods. > 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? That presentation that you linked to says to use struct embedding aka composition. And if you don't want to do that then I'd say you're "probably" framing the problem wrong, but we really need a more concrete example to discuss this further otherwise we'll just be talking past each other.

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