Underscore was chosen in JS presumably because it is a valid variable name that isn't used for anything. Underscore in Go actually means something, which is why this is actually double-underscore, which makes it even visually more confusing.
The approach is interesting, but I'd really rather see a better name.
Then my hat's off to you. So many times I've critiqued some awful names, just for the package author to dig in and stand on their "rights" or whatever. It will be to your benefit, I think.
My only suggestion would be a meta one, which is that I would suggest using a nice, full name and letting people shortcut it themselves. "un" is hard to search for.
Module systems really ought to allow renaming on import. (Such as: rename individual functions, add a prefix to all of the functions, or even do a regexp style replace of all existing prefixes if any.)
But unfortunately, from a quick glance it looks like Go's doesn't, is that correct?
Underscore in Go actually means something, which is why this is actually double-underscore, which makes it even visually more confusing.
It also breaks the conventions for Go package names. Except for the standard library, packages should be in hostname.tld/path/to/repo
e.g.: github.com/ChimeraCoder/anaconda
This is convenient because the import identifier, the relative path to the package on the filesystem (using $GOPATH as the root), and the location of the package on the Web are all the same.
If I saw this as an import, I would be confused as to where to go to find the canonical URL for the package.
It's possible to 'go get' this package using the import path "github.com/tobyhede/underscore.go/src". This import path does not follow Go conventions because the last element of the path is not the same as the package name. Otherwise, the path "github.com/tobyhede/underscore.go/src" follows Go conventions.
Comments
Underscore was chosen in JS presumably because it is a valid variable name that isn't used for anything. Underscore in Go actually means something, which is why this is actually double-underscore, which makes it even visually more confusing.
The approach is interesting, but I'd really rather see a better name.
It looks like the underscore naming is used to benefit from recognized branding of the JS library, not because it's the best name for a Go package.
Yeah, that's the general feedback I've had. Happy to take suggestions.
"un" or "us" might be preferable?
Then my hat's off to you. So many times I've critiqued some awful names, just for the package author to dig in and stand on their "rights" or whatever. It will be to your benefit, I think.
My only suggestion would be a meta one, which is that I would suggest using a nice, full name and letting people shortcut it themselves. "un" is hard to search for.
I went with "un" refactoring last night. But yeah, maybe a longer name is better.
un.Map, un.Reduce have a certain ring to them.
It's Python all over again.
Totally agreed. I'd probably prefer to see one or two alphabetic characters as the package name (i.e., us). But that's just me.
Module systems really ought to allow renaming on import. (Such as: rename individual functions, add a prefix to all of the functions, or even do a regexp style replace of all existing prefixes if any.)
But unfortunately, from a quick glance it looks like Go's doesn't, is that correct?
You can rename the package on import http://play.golang.org/p/V01jD_EZyX
It does. See http://golang.org/ref/spec#Import_declarations
It also breaks the conventions for Go package names. Except for the standard library, packages should be in hostname.tld/path/to/repo
e.g.: github.com/ChimeraCoder/anaconda
This is convenient because the import identifier, the relative path to the package on the filesystem (using $GOPATH as the root), and the location of the package on the Web are all the same.
If I saw this as an import, I would be confused as to where to go to find the canonical URL for the package.
It's possible to 'go get' this package using the import path "github.com/tobyhede/underscore.go/src". This import path does not follow Go conventions because the last element of the path is not the same as the package name. Otherwise, the path "github.com/tobyhede/underscore.go/src" follows Go conventions.
Yeah. The packages isn't correctly formatted ... fixing that.