Helper to get PeerInfo from Host

[raulk]

Trivial change to make this easier based on user feedback.

go-libp2p-host already imports the go-libp2p-peerstore, so no strings attached.

[Stebalien]

This should probably get a test.

[raulk]

@Stebalien didn't think it would add much value, since the function just creates a struct, but I pushed it in 1edd98c. Couldn't think of a way other than creating a mock host, or importing another module (which we don't want to do). LGTY?

[raulk]

Alternatively we could have an interface that's a partial view on Host with only ID() and Addrs(), but I really don't want to do that as it also reduces discoverability by the libp2p newbie.

[Stebalien]

Oh, nevermind. I'm just working on a knee-jerk needs-test reaction. The test is more likely to break than the code.

[raulk]

@Stebalien I feel you; I'll rm this test.

[lthibault]

Why does this new function return a *PeerInfo when methods like Host.Connect take a concrete PeerInfo?

The API seems quite inconsistent, here. Am I missing something?

[raulk]

@lthibault for consistency with pstore.InfoFromP2pAddr() and pstore.InfoToP2pAddrs(), both of which use pointers.

We do return a concrete PeerInfo, just allocated in the heap.

[lthibault]

@raulk

We do return a concrete PeerInfo, just allocated in the heap.

Are you using the term "concrete" to mean "not an interface"? If so, this is just semantics :)

More to the point, shouldn't Host.Connect() take a pointer, then? Again, this makes the API feel quite inconsistent from the outside.

[raulk]

@lthibault it could, but i don't really see the value. Pointers don't make an API feel inconsistent; they're used for technical reasons. The actual types are the same.

That said, these structs are small enough that copy-on-return wouldn't hurt. But this change is not worth the breakage.

[Stebalien]

Yeah, in most places we try to return these by value but it's really not that much of an issue (and I agree with being consistent).