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

net: Expose return values of default implementations of net.Addr.Network() as constants rather than hardcoded strings #11731

Open
srinathh opened this Issue Jul 16, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@srinathh
Contributor

srinathh commented Jul 16, 2015

Currently the default implementations of net.Addr.Network() functions in the net package return hard-coded strings representing the network type as below. This means that callers wanting to check the return value of these functions also have to hard-code these in their own code with the possibilities of typos leading to possibility of bugs.

  • IPAddr.Network() : "ip"
  • IPNet.Network() : "ip+net"
  • TCPAddr.Network() : "tcp"
  • UDPAddr.Network() : "udp"
  • UnixAddr.Network() : "unix" or "unixgram" or "unixpacket"

If we expose these default return strings as package constants and have functions use the constants instead of hard-coded strings, callers can compare function return values against constants and be protected against these types of bugs. This would also be fully backwards-compatible.

A block of constants will also serve as a useful single point of reference in the documentation for these functions as currently we need to jump around the documentation to understand what each implementation returns.

Happy to work out a CL for this

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 16, 2015

CC @mikioh

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 16, 2015

@srinathh

This comment has been minimized.

Contributor

srinathh commented Jul 17, 2015

@mikioh @ianlancetaylor
As i'm going into the net package sources in detail, there's a LOT of usage of hardcoded strings for network address names in the code and implementing a fix for this issue will mean probably 150+ small changes throughout the package sources - essentially replacing many uses of strings like "ip", "ip+net" or "unixgram" with constants like possibly IPAddrName, IPNetAddrName or UnixGramAddrName (perhaps we could come up with better names).

The question i have is might it adversely impact maintainability of the package to make such changes in so many places? The alternative would be to simply define an exported constant block in src/net/net.go for external use but not use the constants internally

@mikioh

This comment has been minimized.

Contributor

mikioh commented Jul 17, 2015

@srinathh,

I think the returned values of Addr.Network are just for fault localization, and are not designed for the case such as "callers can compare values against constants." Please remember that we can use type assertions. So I don't see any benefit from exposing such network names as constants. Instead, from fault localization point of view, I'd like to make Addr.Network return more accurate network names like OpError; e.g., "tcp4" or "tcp6" rather than "tcp".

@srinathh

This comment has been minimized.

Contributor

srinathh commented Jul 17, 2015

Yup - I understand that we can use type assertions or type switches and for what i was developing, i ended up going that route ultimately. However, I did spend some time trying to figure out how to use Addr.Network() since that seemed easier & possibly faster. If the interface is meant more for internal use/debugging, it might be better to document that explicitly in the Addr interface and ask people to use type assertions instead.

Wouldn't changing what Addr.Network returns break compatibility?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment