Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename IpfsDHT to Node #223

Closed
wants to merge 2 commits into from
Closed

Rename IpfsDHT to Node #223

wants to merge 2 commits into from

Conversation

anacrolix
Copy link
Contributor

Renames IpfsDHT to Node per #191 (comment), and adds an alias for compatibility. It doesn't rename the receivers (which are all dht, and probably be node), or the constructors (NewDHT and friends). Those are easy enough to do subsequently if the PR is accepted. Tested against go-libp2p-daemon, which is the main libp2p consumer of this package at present.

@ghost ghost assigned anacrolix Jan 10, 2019
@ghost ghost added the status/in-progress In progress label Jan 10, 2019
Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we at least call it DHTNode? Node is just too generic a name... and I personally prefer just DHT.

// It is used to implement the base IpfsRouting module.
type IpfsDHT struct {
type Node struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're keeping this struct public, I'd rather prefix it with DHT, and remove the DHT from the functions below.
But actually I wonder if there's any use case to keep Node public; I suspect no. In that case I'd be happy with an unqualified node type demoted to private scope.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interface is wider than the routing interface; we would need a new interface for the DHT.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To my knowledge, returning a private type allows consumers to access all its public methods, so you don't need to access them through an interface. In this case, the benefit is that it disallows constructing a struct by itself, and it doesn't leak the unqualified Node type to the public namespace.

BTW – I generally agree that there may be more interfaces to extract.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't construct a variable of it's type though, so you can't assign it anywhere which makes it borderline useless.
Note that the interface of the DHT is wider than any extant interface we have.

Copy link
Member

@raulk raulk Jan 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, you can assign it to a local variable with the := operator, but to pass it around in function arguments, you need to declare those args as interfaces. I'd argue that's the correct way, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be a public type, and that type should be returned explicitly by its constructors. See the Go idiom on returning concrete types and accepting interfaces.

@@ -95,7 +97,7 @@ func New(ctx context.Context, h host.Host, options ...opts.Option) (*IpfsDHT, er
// NewDHT creates a new DHT object with the given peer as the 'local' host.
// IpfsDHT's initialized with this function will respond to DHT requests,
// whereas IpfsDHT's initialized with NewDHTClient will not.
func NewDHT(ctx context.Context, h host.Host, dstore ds.Batching) *IpfsDHT {
func NewDHT(ctx context.Context, h host.Host, dstore ds.Batching) *Node {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we take the plunge and rename this func to NewNode? It's more idiomatic in Go, as the package is already named dht:

node := dht.NewNode()

We'd need to introduce a method alias, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I concur. I also want to rename NewDHTClient to NewClientNode, or NewPassiveNode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's not unnecessarily break existing code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alias would be added for a period for backwards compatibility until the next major version.

@@ -107,15 +109,15 @@ func NewDHT(ctx context.Context, h host.Host, dstore ds.Batching) *IpfsDHT {
// host. IpfsDHT clients initialized with this function will not respond to DHT
// requests. If you need a peer to respond to DHT requests, use NewDHT instead.
// NewDHTClient creates a new DHT object with the given peer as the 'local' host
func NewDHTClient(ctx context.Context, h host.Host, dstore ds.Batching) *IpfsDHT {
func NewDHTClient(ctx context.Context, h host.Host, dstore ds.Batching) *Node {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the above comment, this could become:

func NewClient(ctx context.Context, h host.Host, dstore ds.Batching) *node {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that while you can return private types and still operate on them, they're concealed from docs and a bit dubious. Unfortunately being able to arbitrarily instantiate any public type without going through a constructor is just a Go wart, and not worth trying to evade.

@anacrolix
Copy link
Contributor Author

I think we could retain IpfsDHT for backwards compatibility with the various interfaces people expect of the DHT, and break out Node as the actual DHT implementation. I'll close this for now, as it's easy enough to regenerate in the future when we have more information.

@anacrolix anacrolix closed this Jan 22, 2019
@ghost ghost removed the status/in-progress In progress label Jan 22, 2019
@anacrolix anacrolix mentioned this pull request Jan 22, 2019
@anacrolix anacrolix deleted the rename-ipfsdht branch January 23, 2019 23:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants