On Tuesday, 2 October 2018 04:30:54 UTC+5:30, Robert Engels wrote: > > > On Oct 1, 2018, at 4:59 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > On Mon, Oct 1, 2018 at 1:53 PM, robert engels <ren...@ix.netcom.com > <javascript:>> wrote: > > > If you go to the TCPConn SetReadDeadline function, it states “implements > the Conn SetReadDeadline method”, with no way of referencing the > documentation for Conn.SetReadDeadline, in fact, no way of even getting to > the Conn interface… who knows what Conn is ??? Assume it is a Conn returned > by Dial? How do you determine this? > > > You're right, that is kind of useless. Would you mind filing an issue > about that? It should be fixed one way or another. > > > I will do so. > > > There are already issues filed to track all of these.
https://github.com/golang/go/issues/25444 https://github.com/golang/go/issues/20131 https://github.com/golang/go/issues/5860 > > Furthermore, it is not completely specified, meaning if the read timeout > occurs, and some data was read, is it discarded? will it be returned with > the next read (if any)? Doesn’t say... > > > The behavior of the standard Read method when an error occurs is > documented by the io.Reader interface. > > > But that is kind of the problem, without an ‘implements’ keyword, I would > think that the documentation needs to be specify exactly what interfaces it > “implements”. How do I KNOW that the read on on UDP connection is intended > to be an io.Reader ? It may be “self evident” for the “stdlib” interfaces, > or the de-facto expected behavior, but it gets far trickier when the > interface is not a standard one. > > If Go doesn’t have (or want), “implements”, there needs to be a way for > the documentation to declare the ‘implemented’ interfaces as expected by > the author. > > For example, here is the documentation for UDPConn: > > UDPConn is the implementation of the Conn and PacketConn interfaces for > UDP network connections. > > type UDPConn struct { > // contains filtered or unexported fields > } > > Again, which Conn, and which PacketConn, and if I have a Conn, and look at > the (net.Conn) interface (below) it doesn’t state the Read method functions > according to the io.Reader interface anywhere that I can determine... > > // Read reads data from the connection. > // Read can be made to time out and return an Error with Timeout() == true > // after a fixed time limit; see SetDeadline and SetReadDeadline. > Read(b []byte) (n int, err error) > > > > Maybe I am looking at it wrong, but I think Go’s “simplicity” cannot be > extended to the specifications, especially when dealing with low-level > networking, api, etc. It makes it very difficult to use, and be able to > guarantee it will work the same on all platforms - hurting the portability. > > > I'm not really sure what you're thinking of here. > > > Pretty much inline with the previous sentiment. I just got done writing > the LRMP protocol project, and I’ve done a LOT of networking code in many > languages and platforms, and doing it in Go was more of a pain than I think > it should of been. The documentation is just not ‘linked/reference’ in a > way that is needed when you have dynamic interfaces. For example, similar > problems with PacketConn - there are multiple PacketConn interfaces and it > is nearly impossible to figure out “what is what” by reading the > documentation. It often just states return a PacketConn, without a link to > the specific PacketConn . To further the example, if you work with > ipv4.PacketConn, is it a net.PacketConn? No way to know / see the hierarchy > with out coding it and looking for errors…. Very inefficient. > > > Ian > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
