Hi, On Apr 23, 2014, at 7:25 AM, Garrett D'Amore wrote: > So the first stage of refactoring is done. > > This stage is the *protocols*, which all live now in separate packages. And > the strings for protocol names are completely gone. There was no value in > them (as others have pointed out). > Nice1 > To get a protocol just do: > > import ( “bitbucket.org/gdamore/mangos/protocols/req”) // replace “req” with > which protocol you want > > s, err := req.NewSocket() // or pub.NewSocket(), etc... > > Then do operations on the socket. Its that easy. The string based registry > of protocol names, and factories are *gone*. > Yeah, this looks pretty nice. In any case wow, you are fast to act :-) Ondrej > I can make “predefined” raw versions like “xreq” and company if folks prefer > that to SetOption(OptionRaw, …) > > This proves that the protocols are nice and modular, and we can add new > patterns/protocols very easily. Yay! > > The transports are next. > > Here’s what the start of macat looks like now: > > package main > > import ( > "bufio" > "encoding/binary" > "errors" > "fmt" > "io/ioutil" > "os" > "strconv" > "strings" > "time" > ) > > import ( > "bitbucket.org/gdamore/mangos" > "bitbucket.org/gdamore/mangos/protocol/bus" > "bitbucket.org/gdamore/mangos/protocol/pair" > "bitbucket.org/gdamore/mangos/protocol/pub" > "bitbucket.org/gdamore/mangos/protocol/pull" > "bitbucket.org/gdamore/mangos/protocol/push" > "bitbucket.org/gdamore/mangos/protocol/rep" > "bitbucket.org/gdamore/mangos/protocol/req" > "bitbucket.org/gdamore/mangos/protocol/respondent" > "bitbucket.org/gdamore/mangos/protocol/star" > "bitbucket.org/gdamore/mangos/protocol/sub" > "bitbucket.org/gdamore/mangos/protocol/surveyor" > "github.com/droundy/goopt" > ) > > The other transport refactoring will add a couple more imports. But I’m > thinking for the transport layer, having the “all” special package would be > more useful. (I agree that there is little value in doing this for > protocols, since the app should *really* know what protocol(s) it wants to > support.) > > I’ve also moved the test code (most of it any way) into a separate test/ > package. This was the only way I could keep things sane without having to > document a bunch of test framework related stuff. > > -- > Garrett D'Amore > Sent with Airmail > > On April 22, 2014 at 1:40:31 PM, Ondrej Kupka (ondra.cap@xxxxxxxxx) wrote: > >> Hi, >> >> On Apr 22, 2014, at 10:35 AM, Garrett D'Amore wrote: >> >>> I’ve implemented “macat” (I did say I suck at names right?) which is a drop >>> in replacement for nanocat. Its really handy for testing, since you can >>> have nanocat on one side, and macat on the other. (There are some things I >>> don’t like about nanocat and would like to change, but I thought interop to >>> be more useful for now. Specifically, for some patterns, having a maximum >>> receive count would be a nice feature — e.g. receive only “n” packets, most >>> often going to be just “1” for a one-shot. >>> >>> https://bitbucket.org/gdamore/mangos/src/e70c9eb062957c9908305b95cba12e5d9056ca50/macat/macat.go?at=master >>> >>> This utility does require another 3rd party library for option parsing. >>> (Go’s “flag” package is … lame. Specifically, I need the ability to have >>> repeat options, e.g. multiple instances of “-v” or “—bind” to bind to >>> multiple addresses at once.) >>> >> >> You can do that using "flag". See Value interface. You can simply wrap a >> list or something in this and implement the Set method that would append to >> an internal list or so… >> >> Regards, >> Ondrej >> >>> Anyway, enjoy! >>> >>> -- >>> Garrett D'Amore >>> Sent with Airmail >>