feat: add client to allow passing custom resolver #27
Conversation
babariviere
force-pushed
the
feat/add-client
branch
from
025859c
to
c111a00
Compare
| @@ -11,16 +11,27 @@ import ( | |||
|
|
|||
| const hexDigit = "0123456789abcdef" | |||
|
|
|||
| var DefaultClient = &Client{resolver: net.DefaultResolver} | |||
There was a problem hiding this comment.
| var DefaultClient = &Client{resolver: net.DefaultResolver} | |
| var DefaultDNSClient = &DNSClient{resolver: net.DefaultResolver} |
Let's call it DNSClient for clarity with BulkClient.
| var DefaultClient = &Client{resolver: net.DefaultResolver} | ||
|
|
||
| type Client struct { | ||
| resolver *net.Resolver |
There was a problem hiding this comment.
I believe we should export resolver and then remove NewClient. The New abstraction is a bit premature.
There was a problem hiding this comment.
If I do this, users of this lib will be able to create a Client without resolver, and this will lead to a crash.
So I would have to add a check on each function to ensure we have at least the default resolver.
There was a problem hiding this comment.
That panic still exists if you instantiated a DNSClient and ignored the New function.
If you're creating a DNSClient (or any foreign struct) you should probably glance at the fields.
Also, a New API here obscures the name of the fields (function calls are unkeyed) leading a more cognitive overhead when reviewing code, and makes the otherwise simple DNSClient type mysterious. My preference is to only introduce a New function when either:
- The struct has complex initialization logic
- Only some of the struct's fields are required (and it's not as simple as public = required, private = not)
Close #26