Closed sashaafm closed 3 years ago
The struct internals are private so the user experience is not affected by the field names being different. I don't believe we access these fields internally outside of the current module so the experience when developing the library itself should not be affected either.
Hi @ericmj, I understand your point. Do you reckon a top-level Mint.HTTP.hostname/1
function make sense? This function would return the hostname
independent of the underlying connection being Mint.HTTP1
or Mint.HTTP2
.
We could add such a function but I am not sure it's necessary, the user passed the hostname to Mint so the user should already know what the hostname is. I think it's better if the user stores this data alongside the connection struct otherwise we would need to add a lot of access functions for all the data that is stored on the connection struct.
@ericmj I understand your point and I think you're right 🙂 the user should already know what the hostname is.
Thank you for your time.
Hello 👋 I've started using this great library and so far it has provided an amazing UX!
I've noticed the field related to the connection's URL host differs between
Mint.HTTP1
andMint.HTTP2
. The first has a struct with this field named ashost
while the second one has this same field ashostname
.From my research this isn't something defined by either version of the protocol? If this is just a case of each struct being named differently for no reason could it be altered to both having the same field name? I believe
hostname
would be the best option for both as it is clear what it represents.The main use-case for this change would be to provide the most similar interface between both version of the protocol, thus offering a better developer experience.
If you agree with this change I'd be happy with attempting to submit a PR to fix this issue.
Thanks 😄