code review 35940049: go.tools/go/types: print interface methods in sorted order

go.tools/go/types: print interface methods in sorted order

Required for testing code of clients.

[gri, 2013-12-16 19:45:55]

Hello adonovan@google.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go.tools

[adonovan, 2013-12-16 19:56:29]

LGTM

https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go
File go/types/typestring.go (right):

https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go#new...
go/types/typestring.go:89: // This us needed at the moment because interfaces
interfaces
s/us/is/
s/interfaces interfaces/interfaces/

Wondering whether this list could contain duplicates, I just learned that it's
an error for a method to appear in an embedded and an outer interface, or in two
embedded interfaces.  (This is quite surprising, since I would think it's both
simple, obvious and useful to do that.)  Among other things, it suggests that it
is a bad idea for interfaces to include (e.g.) 'String() string' to force their
implementations to be stringable, since then you can't put two such things
together.

[gri, 2013-12-16 21:33:43]

Hello adonovan@google.com (cc: golang-dev@googlegroups.com),

Please take another look.

[gri, 2013-12-16 21:34:24]

https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go
File go/types/typestring.go (right):

https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go#new...
go/types/typestring.go:89: // This us needed at the moment because interfaces
interfaces
On 2013/12/16 19:56:30, adonovan wrote:
> s/us/is/
> s/interfaces interfaces/interfaces/
> 
> Wondering whether this list could contain duplicates, I just learned that it's
> an error for a method to appear in an embedded and an outer interface, or in
two
> embedded interfaces.  (This is quite surprising, since I would think it's both
> simple, obvious and useful to do that.)  Among other things, it suggests that
it
> is a bad idea for interfaces to include (e.g.) 'String() string' to force
their
> implementations to be stringable, since then you can't put two such things
> together.
>  

Interfaces have no notion of "field" access at the moment; and w/o such a
mechanism it wouldn't be possible to select a specific duplicate embedded
method. But yes, I think one probably could make it work.

[adonovan, 2013-12-16 21:50:48]

On 2013/12/16 21:34:24, gri wrote:
> https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go
> File go/types/typestring.go (right):
> 
>
https://codereview.appspot.com/35940049/diff/40001/go/types/typestring.go#new...
> go/types/typestring.go:89: // This us needed at the moment because interfaces
> interfaces
> On 2013/12/16 19:56:30, adonovan wrote:
> > s/us/is/
> > s/interfaces interfaces/interfaces/
> > 
> > Wondering whether this list could contain duplicates, I just learned that
it's
> > an error for a method to appear in an embedded and an outer interface, or in
> two
> > embedded interfaces.  (This is quite surprising, since I would think it's
both
> > simple, obvious and useful to do that.)  Among other things, it suggests
that
> it
> > is a bad idea for interfaces to include (e.g.) 'String() string' to force
> their
> > implementations to be stringable, since then you can't put two such things
> > together.
> >  
> 
> Interfaces have no notion of "field" access at the moment; and w/o such a
> mechanism it wouldn't be possible to select a specific duplicate embedded
> method. But yes, I think one probably could make it work.

LGTM

[gri, 2013-12-16 21:53:03]

*** Submitted as
https://code.google.com/p/go/source/detail?r=f5af84eb78e1&repo=tools ***

go.tools/go/types: print interface methods in sorted order

Required for testing code of clients.

R=adonovan
CC=golang-dev
https://codereview.appspot.com/35940049