In both Java and C++ (statically compiled languages), Google's style guides
prohibit "wildcard"-style imports of an entire library:
https://google.github.io/styleguide/javaguide.html#s3.3.1-wildcard-imports
https://google.github.io/styleguide/cppguide.html#Namespaces
I believe the restriction is there to allow library authors to add names to
their library over time without the risk of changing the meaning of calling
code (or making that code fail to compile).
I used to find working with Java imports fairly unpleasant as it requires
editing imports once for every type mentioned, rather than every package.
Luckily, there is goimports-inspired tooling for this (although it is much
slower, sadly).
In any case, I can maybe see why you'd want to use unqualified types, but
it seems valuable to know at the use-site which identifiers originate in
different packages, and which must originate in the same package. That
value seems worth prohibiting dot-imports. You occasionally have to deal
with things like "context.Context", but they are the exception not the rule
(there are more names in the io package alone than have been mentioned as
stutter here in this thread).
Sanjay
On Saturday, December 1, 2018 at 10:44:05 PM UTC-8, robert engels wrote:
>
> I think it is especially problematic for python because:
>
> import * + type inference + dynamic language = hell
>
> in my book.
>
> > On Dec 2, 2018, at 12:26 AM, Ian Denhardt <i...@zenhack.net
> <javascript:>> wrote:
> >
> > Quoting robert engels (2018-12-02 00:59:31)
> >
> >> Granted, their package structure seems poor in my opinion, but you
> >> can't talk bad about k8s.
> >
> > Of course you don't lose anything by getting rid of the package names if
> > the package structure doesn't make any sense in the first place.
> >
> >> And probably the most common method signature of them all:
> >>
> >> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
> >>
> >> are you losing anything if this is:
> >> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
> >
> > No, and I would go further (if Go permitted it):
> >
> > http.HandleFunc("/bar", func(w, r) {
> > ...
> > })
> >
> > http.HandleFunc is so well known that having the types there at all is
> > just noise. But I know you don't like type inference.
> >
> >> All coding requires good development choices - there are many times
> it
> >> probably shouldn't be used - but I making a blanket statement its
> bad
> >> seems like overreach.
> >
> > It's bad enough that common Python linters will flag it, and a lot of
> > large python projects do ban it outright.
> >
> > Note that nobody in Python land complains about:
> >
> > from foo import bar, baz
> >
> > ..the equivalent of which is what I've seen in what Java code I have
> > looked at. Rather, the suspect construct is:
> >
> > from foo import *
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
