On 14 December 2016 at 21:11, Dave Cheney <d...@cheney.net> wrote:
> I've retired hurt from the alias debate, but I'll bet you a steak dinner
> next time I'm in NYC that aliases will have caused an unexpected increase in
> circular dependency problems because aliases obscure the true declaration of
> a symbol.
The nice thing about circular dependency issues is that there's a hard
line there
that the compiler won't let you step over. You either have a circular dependency
or you don't - there is no slippery slope.
FWIW I suspect that the use of aliased types may *reduce* the number
of circular dependency
issues because if you have smaller packages with well delineated
concerns, you're
likely to get less spurious dependencies caused by features that you don't use.
To take net/http as an example. If http.Header was just an alias to
net/textproto/MimeHeader
(it is already very close), then to declare or define a value that
uses http.Header would
need only 34 package dependencies rather than 108 because you could just use
textproto.MimeHeader directly and it would still be compatible.
In my experience it is very common for circular dependencies to arise
not because
of something in a package that I'm using directly, but because of
something semi-related that
happens to sit in the same package.
cheers,
rog.
--
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.
