Re: [go-nuts] Re: navigating through interface calls
When using IntelliJ, did you restrict the search to “project files”? Otherwise
you will get implantations anywhere in the standard library or other projects.
> On Dec 10, 2018, at 6:21 AM, David Wahlstedt
> wrote:
>
> Hi, and thanks for your answers!
> Yes, I realize that the possible results of calling an interface method
> depends on runtime. But in many cases there is only one possible alternative,
> or just a few ones, dependent of the state of the program. It should still be
> possible for the tool to compute the possible candidates, and omit irrelevant
> matches. In my example there was only one possible alternative, although
> go-guru showed a list of many other alternatives.
> By the way, I also tried IntelliJ(goland) as well as visual studio and
> LiteIDE X X35.2, and none of them gave more information than go-guru in this
> matter.
>
> /David
>
>> Den fredag 7 december 2018 kl. 17:53:03 UTC+1 skrev David Wahlstedt:
>> Hi,
>> I am still quite inexperienced in go programming, and I find it quite
>> frustrating, sometimes, to find what will actually be executed by a call to
>> an interface method found in some arbitrary code.
>> Here I have traced the process of finding the definition of "conn.Close()"
>> an instance of an interface method call. This is what I would like to have
>> automatized by godef, for instance.
>> Is there anything like that out there that does it with one command / key
>> stroke, etc, automagically ?
>> Godef and go-guru does not, as far as I know.
>>
>> BR,
>> David
>>
>> Here follows some anonymized code:
>> (please forgive me if I've made some errors, I hope you get the idea anyway)
>>
>> In the file file1.go:1234 in the library lib1, I found a call:
>> :_ = conn.Close()
>> How do i figure out what happens when this line is executed?
>> Here is a list of steps to find it "mechanically", so to say:
>> 1. file1.go:1234
>>: func returnConn(conn lib2.Conn) {
>>: _ = conn.Close()
>>: }
>>
>>Using godef-jump on the Close() will just give me the interface
>>declaration. I can use go-guru-implements, and get a list of
>>possible implementations of Close, but how do I know which one will
>>actually be used? So, let's figure out the actual type of conn.
>>I use go-guru-referrers on returnConn, and choose one of the hits,
>>which is file1.go:206
>>
>> 2. file1.go:206
>>: func (r *Record) Release(foo bar.T1) error {
>>: ...
>>: var conn lib2.Conn
>>: if conn, err = r.foo.getConn(baz); err != nil {
>>: return err
>>: }
>>: defer returnConn(conn)
>>conn gets its value from getConn, so I end up in file1.go:1074
>>
>> 3. file1.go:1074
>>: func (foo *FOO) getConn(mu T2) (lib2.Conn, error) {
>>: ...
>>: conn := foo.connBax.Get()
>>: ...
>>: return conn, nil
>>conn gets its value from Get(), so I go to file3.go:178
>>
>> 4. file3.go:178
>>: func (p *Bax) Get() Conn {
>>: ...
>>: return &xooConn{x: p, xc: xc}
>>I find the return value and go to its definition in file3.go:371
>>
>> 5. file3.go:371
>>: type xooConn struct {
>>: x *Bax
>>: xc*baxConn
>>: s T3
>>: }
>>Aaah! This is the type of conn at file1.go:1234!
>>
>> 6. file1.go:1234
>>: _ = conn.Close()
>>Now I can follow the "definition" of Close() using godef-jump, and
>>end up in file1.go:30:
>>
>> 7. file1.go:30
>>: type Conn interface {
>>: Close() error
>>
>>I use go-guru-implements to see a list of possible implementations:
>>: PATH1/lib2/dir1/file1.go:30.2-30.6: abstract method func
>> (ConnWithTimeout).Close() error
>>: PATH1/lib2/dir1/file3.go:394.23-394.27: is implemented by
>> method (*xooConn).Close
>>: PATH1/lib2/dir1/conn.go:304.16-304.20: is implemented by method
>> (*conn).Close
>>: PATH1/lib2/dir1/boo.go:12.3-45.6: is implemented by method
>> (*booingConn).Close
>>: PATH1/lib2/dir1/file3.go:510.21-510.25: is implemented by
>> method (errorConn).Close
>>: PATH1/lib2/dir1/file1.go:30.2-30.6: implements method (Conn).Close
>>: PATH2/bah.go:78.9-101.2:implements method (bah.Closer).Close
>>Now, since I know the type is *xooConn, I can jump to the right hit,
>>and go to file3.go:394.
>> 8. file3.go:394
>>: func (ac *xooConn) Close() error {
>>: pc := ac.pc
>>: ...
>>: return nil
>>Yes, here it is, at step 8
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
T
[go-nuts] Re: navigating through interface calls
Hi, and thanks for your answers!
Yes, I realize that the possible results of calling an interface method
depends on runtime. But in many cases there is only one possible
alternative, or just a few ones, dependent of the state of the program. It
should still be possible for the tool to compute the possible candidates,
and omit irrelevant matches. In my example there was only one possible
alternative, although go-guru showed a list of many other alternatives.
By the way, I also tried IntelliJ(goland) as well as visual studio and
LiteIDE X X35.2, and none of them gave more information than go-guru in
this matter.
/David
Den fredag 7 december 2018 kl. 17:53:03 UTC+1 skrev David Wahlstedt:
>
> Hi,
> I am still quite inexperienced in go programming, and I find it quite
> frustrating, sometimes, to find what will actually be executed by a call to
> an interface method found in some arbitrary code.
> Here I have traced the process of finding the definition of "conn.Close()"
> an instance of an interface method call. This is what I would like to have
> automatized by godef, for instance.
> Is there anything like that out there that does it with one command / key
> stroke, etc, automagically ?
> Godef and go-guru does not, as far as I know.
>
> BR,
> David
>
> Here follows some anonymized code:
> (please forgive me if I've made some errors, I hope you get the idea
> anyway)
>
> In the file file1.go:1234 in the library lib1, I found a call:
> : _ = conn.Close()
> How do i figure out what happens when this line is executed?
> Here is a list of steps to find it "mechanically", so to say:
> 1. file1.go:1234
>: func returnConn(conn lib2.Conn) {
>: _ = conn.Close()
>: }
>
>Using godef-jump on the Close() will just give me the interface
>declaration. I can use go-guru-implements, and get a list of
>possible implementations of Close, but how do I know which one will
>actually be used? So, let's figure out the actual type of conn.
>I use go-guru-referrers on returnConn, and choose one of the hits,
>which is file1.go:206
>
> 2. file1.go:206
>: func (r *Record) Release(foo bar.T1) error {
>: ...
>: var conn lib2.Conn
>: if conn, err = r.foo.getConn(baz); err != nil {
>: return err
>: }
>: defer returnConn(conn)
>conn gets its value from getConn, so I end up in file1.go:1074
>
> 3. file1.go:1074
>: func (foo *FOO) getConn(mu T2) (lib2.Conn, error) {
>: ...
>: conn := foo.connBax.Get()
>: ...
>: return conn, nil
>conn gets its value from Get(), so I go to file3.go:178
>
> 4. file3.go:178
>: func (p *Bax) Get() Conn {
>: ...
>: return &xooConn{x: p, xc: xc}
>I find the return value and go to its definition in file3.go:371
>
> 5. file3.go:371
>: type xooConn struct {
>: x *Bax
>: xc*baxConn
>: s T3
>: }
>Aaah! This is the type of conn at file1.go:1234!
>
> 6. file1.go:1234
>: _ = conn.Close()
>Now I can follow the "definition" of Close() using godef-jump, and
>end up in file1.go:30:
>
> 7. file1.go:30
>: type Conn interface {
>: Close() error
>
>I use go-guru-implements to see a list of possible implementations:
>: PATH1/lib2/dir1/file1.go:30.2-30.6: abstract method func
> (ConnWithTimeout).Close() error
>: PATH1/lib2/dir1/file3.go:394.23-394.27: is implemented by method
> (*xooConn).Close
>: PATH1/lib2/dir1/conn.go:304.16-304.20: is implemented by method
> (*conn).Close
>: PATH1/lib2/dir1/boo.go:12.3-45.6: is implemented by method
> (*booingConn).Close
>: PATH1/lib2/dir1/file3.go:510.21-510.25: is implemented by method
> (errorConn).Close
>: PATH1/lib2/dir1/file1.go:30.2-30.6: implements method (Conn).Close
>: PATH2/bah.go:78.9-101.2: implements method (bah.Closer).Close
>Now, since I know the type is *xooConn, I can jump to the right hit,
>and go to file3.go:394.
> 8. file3.go:394
>: func (ac *xooConn) Close() error {
>: pc := ac.pc
>: ...
>: return nil
>Yes, here it is, at step 8
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: navigating through interface calls
It is rather the point of interfaces that there IS no fixed definition of an instance of an Interface call. The definition could be that of ANY struct that matches that interface, depending on what is passed. So yes, you have to find AN instance of a call to the function that accepts an interface, to find out what it is calling. Because if you call it with a different struct, it calls that struct's implementation. Kind of the point. And finding that implementation for that call does not guarantee that the next call may not be calling a different implementation, because it is being passed a different struct. Your steps after 5 seemed a bit unnecessary - just go to the definition of xooConn, your step 5, and search for Close. While it is possible to implement a function on a struct elsewhere, the likelihood is pretty low, and if you don't find it, then you can go on to your other steps. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
