Great, maybe I can find some time and contribute back… I think it would go a long way towards working with complex hierarchy systems easier.
> On Oct 1, 2018, at 11:36 PM, Agniva De Sarker <agniva.quicksil...@gmail.com> > wrote: > > > > 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 <>> wrote: >> >> On Mon, Oct 1, 2018 at 1:53 PM, robert engels <ren...@ix.netcom.com <>> >> 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
