Closed gaukas closed 1 year ago
As you can see in the type definition our Listener/Conn actually either embeds the net type (Conn embeds net.Conn) or resembles the net type (Listener is net.Listener with Accpet() modified to return Conn instead).
I am also a bit uncertain about the change on Accept(). Any suggestions? How about change it to embed net.Listener with AcceptWATER() which returns water.Conn? It will be more net-ish (like, net.TCPListener.AcceptTCP).
I guess the test is whether it can be cast / used as the interface externally by a caller, i.e.
var wListener net.Listener = water.Config{...}.Listen(...)
listenAndAccept(ln)
func listenAndAccept(ln net.Listener) error{
for {
c, _ := ln.Accept()
handle(c)
}
}
func handle(c net.Conn) error { ...
or transformed / accessed I guess, if this doesn't work we could do something like AsNetListener or AsNetConn that returns something implementing that interface. But that seems like extra steps for the same outcome
We can always make this the defacto for like internal usage. But for external APIs we want to try to present a consistent interface. I.E. is there somethings that we expect callers to be doing with a water.Conn
that they can't do with a net.Conn
or is it that we need to use it as a water.Conn
?
You had a point. For it to pass the type assertion against net.Listener, the changes proposed above by me is pretty much needed. The type in the function prototype won't be inferred as interfaces it implements.
Just to clear things a bit: Currently water.Listener is essentially just a net.Listener but in the future we may found some extra functions useful to add. So I found it helpful to at least have a natural way of directly getting a water.Conn out of the water.Listener.
Typical users may keep using net.Listener interface and operate on net.Conn, but advanced users may prefer (water.Listener).AcceptWATER (just like net.TCPListener).AcceptTCP.)