improvement: v0 enhancement and fix

[gaukas]

• Rename v0plus to v0. v0plus is an internal code reference only.
• Fix README.md.
• Minor changes to interfaces.
• Add test suites for Dialer/Listener/Relay in v0.

[gaukas]

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).

[jmwample]

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?

[gaukas]

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.)