Further to this, you can see that having two diametrically opposite
claims (1. UDPConn.Read implements Conn.Read and Conn is a generic
stream-oriented network connection cf 2. UDP is not stream oriented)
might be somewhat confusing.
On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote:
> And the
No worries. Thanks for trying.
Dan
On Sun, 2019-05-12 at 22:10 -0500, robert engels wrote:
> I am sorry if you think I was not helpful, nor friendly - I was
> trying to be both.
>
> That is why I took the time to pass on the relevant documentation,
> and code.
>
> >
> > On May 12, 2019, at 10:
I am sorry if you think I was not helpful, nor friendly - I was trying to be
both.
That is why I took the time to pass on the relevant documentation, and code.
> On May 12, 2019, at 10:04 PM, Dan Kortschak wrote:
>
> Thank you. I have reviewed the code. I was hoping for some friendly and
> hel
Thank you, that has clarified what I was wanting to confirm.
Dan
On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote:
> On Sun, May 12, 2019 at 7:38 PM Dan Kortschak
> wrote:
>
> >
> > Yes, I'm aware of all this. However, the net.UDPConn Read method
> > states
> > that it "Read implements th
Thank you. I have reviewed the code. I was hoping for some friendly and
helpful input.
On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> As I said, I reviewed the code - which you can do as well. It is
> below. At least for “unix-ish” systems - it goes to syscall.Read()
> which is why I li
On Sun, May 12, 2019 at 7:38 PM Dan Kortschak wrote:
> Yes, I'm aware of all this. However, the net.UDPConn Read method states
> that it "Read implements the Conn Read method", and does not the
> io.Reader interface; net.Conn has the explicit method, not an embedding
> of io.Reader.
>
And the Co
As I said, I reviewed the code - which you can do as well. It is below. At
least for “unix-ish” systems - it goes to syscall.Read() which is why I linked
you to the unix documentation on the difference between read() and recv().
Instead of waiting for someone else to confirm, you can think about
Yes, I'm aware of all this. However, the net.UDPConn Read method states
that it "Read implements the Conn Read method", and does not the
io.Reader interface; net.Conn has the explicit method, not an embedding
of io.Reader.
I'd like to hear from someone who contributed to net.
On Sun, 2019-05-12 a
Which is a big problem with the Go “interface” specification…
But the de-facto standard is as I stated - if it implements the method it
implements the interface. There is no requirement that the method/struct “be
documented” to be an implementor - buyer beware!
We is also why you should never
This is not quite true. The language itself doesn't make claims other
than types and method names. However, there are conventions around the
semantics of methods in an interface. For example, a Read method that
returns 0, nil is allowed for io.Reader, but frowned upon unless the
buffer is zero leng
There is no claim because that is not how Go interfaces work - if you implement
it, you are it - that being said, I wouldn’t use Read() with UDPConn - I would
use one of the packet/msg reader methods instead.
Read() is a pass through to fd.Read() so it will be implementation dependent,
but posi
bump?
On Thu, 2019-05-09 at 16:23 +0930, Dan Kortschak wrote:
> The Conn and UDPConn Read methods look like io.Reader Read methods,
> but
> there is no explicit claim that Conn is an io.Reader. Are the Read
> methods of these two types identical in behaviour to io.Reader?
> Specifically, are the r
The Conn and UDPConn Read methods look like io.Reader Read methods, but
there is no explicit claim that Conn is an io.Reader. Are the Read
methods of these two types identical in behaviour to io.Reader?
Specifically, are the reads allowed to fill the buffer with arbitrary
numbers of bytes in 0 <= l
13 matches
Mail list logo
