3 ms·

Can this information be automatically deduced by tools? If so, it's a great opportunity for tools to help out with understanding, while maintaing all the benefi

Can this information be automatically deduced by tools? If so, it's a great opportunity for tools to help out with understanding, while maintaing all the benefits of duck typing when the writing code.

mseepgood 13y ago
> Can this information be automatically deduced by tools? Yes, it can and it should be fairly easy. The Go standard library already has a "go/ast" package. Would probably be similar to this documentation tool: http://code.google.com/p/rspace/source/browse/doc/doc.go?repo=cmd http://code.google.com/p/rspace/source/browse/doc/doc.go?rep...
jstanley 13y ago
Given that it's automatically deduced by the compiler, I would hope so :)
- sirclueless 13y ago
  It's not that simple. I mean, given an os.File and a function that requires an io.Reader, it's pretty straightforward to discover that square peg goes in square hole. But just given either half of the relationship it's not currently so easy: "This function needs an io.Reader, how would I get my hands on one of those?" Go doesn't currently have an easy way to tell you. "This os.File has a bunch of stuff implemented. What can I do with it?" Go doesn't currently have an easy way to tell you. The hard problem that remains to be solved is discovery. Someone somewhere needs to take a good long look at your project, the libraries available on your computer, and the standard library and connect the dots. It should be possible, most IDEs have this for other languages, when Go grows up you would expect these to be flagship features: "Find all known implementations of a given interface" and "Find all interfaces this type satisfies." For example, you might eventually expect the locally generated versions of these two pieces of documentation to refer to each other, even though they currently do not: http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader http://golang.org/pkg/os/#File http://golang.org/pkg/os/#File godoc already aggregates all your local packages' documentation into one place, adding cross-references to known implementations seems like an obvious incremental addition.
  - jstanley 13y ago
    How many interfaces are there? You can iterate over all of them and see if the module implements them. If you are doing this for many modules at a time you can do a lot better by caching signatures.

mseepgood 13y ago

> Can this information be automatically deduced by tools? Yes, it can and it should be fairly easy. The Go standard library already has a "go/ast" package. Would probably be similar to this documentation tool: http://code.google.com/p/rspace/source/browse/doc/doc.go?repo=cmd http://code.google.com/p/rspace/source/browse/doc/doc.go?rep...

jstanley 13y ago

Given that it's automatically deduced by the compiler, I would hope so :)

sirclueless 13y ago
It's not that simple. I mean, given an os.File and a function that requires an io.Reader, it's pretty straightforward to discover that square peg goes in square hole. But just given either half of the relationship it's not currently so easy: "This function needs an io.Reader, how would I get my hands on one of those?" Go doesn't currently have an easy way to tell you. "This os.File has a bunch of stuff implemented. What can I do with it?" Go doesn't currently have an easy way to tell you. The hard problem that remains to be solved is discovery. Someone somewhere needs to take a good long look at your project, the libraries available on your computer, and the standard library and connect the dots. It should be possible, most IDEs have this for other languages, when Go grows up you would expect these to be flagship features: "Find all known implementations of a given interface" and "Find all interfaces this type satisfies." For example, you might eventually expect the locally generated versions of these two pieces of documentation to refer to each other, even though they currently do not: http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader http://golang.org/pkg/os/#File http://golang.org/pkg/os/#File godoc already aggregates all your local packages' documentation into one place, adding cross-references to known implementations seems like an obvious incremental addition.
- jstanley 13y ago
  How many interfaces are there? You can iterate over all of them and see if the module implements them. If you are doing this for many modules at a time you can do a lot better by caching signatures.