[nanomsg] Re: more updates
- From: jimmy frasche <soapboxcicero@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 13:08:10 -0700
> imports
In mangos/transport/tcp you could have it register its factory with
the string required for dial. The tcp package would just need to do:
func init() {
mangos.RegisterTransport("tcp", New) //and whatever other
information is required
}
There could be a ParseAddr helper in mangos that returns the
appropriate protocol and such for subpackages to use.
I don't really see the usefulness of "all" packages. The only
legitimate user I can see that catering to is macat. If someone's
developing an application that uses every package of mangos they
probably have more legitimate code complexity worries than an extra
dozen imports. It also just seems very un-go.
Just in case there is still any confusion about how init works: When I
said it happens "at import time" that was a shorthand. The init
functions within a package are evaluated in an arbitrary order, but
they are always executed before main() and in dependency order. If tcp
imports mangos, then mangos init functions are guaranteed to have
completed before tcp's.
There's no need for a user of package to call Register, it's
completely safe for tcp to do it on the user's behalf in init.
> tests
go test has a very nice benchmarking facility.
Your tests should stick to testing correctness.
If the race detector causes them to go too slowly it's not really
different than running the tests on a much less faster machine.
Even if you could manage to somehow foil it, would it really be worth
possibly not finding a race condition?
> golint
With golint and mangos both at tip, I get:
$ golint *.go
errors.go:22:2: exported var ErrBadAddr should have comment or be unexported
protocol.go:203:2: comment on exported const ProtoStar should be of
the form "ProtoStar ..."
star_test.go:47:62: func parameter numId should be numID
xbus.go:174:5: exported var BusFactory should have comment or be unexported
(etc for the other factories)
The errors.go one is ignorable.
But what led me to say that, foolishly without checking, was that the
Number method of
http://godoc.org/bitbucket.org/gdamore/mangos#Protocol has a comment
saying it's called ProtocolNumber.
I've filed an issue against golint: https://github.com/golang/lint/issues/38
Other related posts:
