I have a package named "foo" because it defines a Foo struct and related stuff like methods.
The package has a New method that returns a heap allocated Foo struct.
Is it Ok to name the struct type Foo when the package name is "foo" ? I'm unsure because it would stutter.
var f foo.Foo
On the other hand it feels natural to write
f := foo.New(...)
分享 It is ok, and it's also idiomatic.
Similar examples from the standard library:
Also, I guess foo.Foo is just an example, but with your actual type names you may also use simplification in the type name, exactly because the package already describes it. For example there is an http.CookieJar interface in the standard lib, and there is a net/http/cookiejar package which provides a type that implements http.CookieJar, and it is named cookiejar.Jar, and not cookiejar.CookieJar.
So just use common sense and look at it from the perspective of the package's users (from their point of view). foo.Foo is perfectly fine. But the similar examples above are part of packages that contain lots of other types. If this is the only type your package will ever export, depending on the usage, foo.F may also be sensible and acceptable. As an example, there are bson.M and bson.D types which are deliberately made short, because they are used often and even multiple times to create MongoDB queries. Given the context it is clear what they are, and does not cause trouble or misunderstanding.
分享
