5 ms·
> The problem is if a package registers some global name, and another copy of the package also registers the same global name, that could cause an error. This
by a13xb 11y ago
> The problem is if a package registers some global name, and another copy of the package also registers the same global name, that could cause an error.
This shouldn't cause an error, because packages can only register globals within their own namespace. You just end up with two copies of it, with different types.
- yoklov 11y agoA separate but more important issue is that you still have two copies of any global state managed by/contained within that library in memory. That is basically guaranteed to lead to bugs.
- nulltype 11y agoOne that definitely happens is if, for instance, a library returns datastore.ErrNoSuchEntity, but vendored the "datastore" package. If you have your own version of "datastore" then you do "err == datastore.ErrNoSuchEntity" and it's false, because there are two copies of ErrNoSuchEntity in memory. This seems pretty solvable though. If you vendor a package, you need to make sure you don't do this. If we do gb-style everyone vendors stuff themselves (not in libraries), then it's not an issue.
- nulltype 11y agoThat would be nice, but that is not true in Go. You can register with a function like this one: http://golang.org/pkg/database/sql/#Register http://golang.org/pkg/database/sql/#Register (mentioned in the article) and run it in your init() function or any similar function that a client calls. That will collide with any other package that also uses that registration function for the same value of 'name'.
- a13xb 11y agoRight, when you leak handles to package objects externally, all bets are off.